From yoshfuji@linux-ipv6.org Sat Nov 1 03:01:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 03:02:02 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA1B1R25009335 for ; Sat, 1 Nov 2003 03:01:28 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-6.6) with ESMTP id hA1B1Wlg018026; Sat, 1 Nov 2003 20:01:33 +0900 Date: Sat, 01 Nov 2003 20:01:32 +0900 (JST) Message-Id: <20031101.200132.55114465.yoshfuji@linux-ipv6.org> To: davem@redhat.com CC: netdev@oss.sgi.com Subject: [PATCH] IPV{4,6}: Fix one more inappropriate use of inet6_sk()->ipv6only From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1166 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello. Sorry, I forgot to fix this one... ===== net/ipv4/tcp_ipv4.c 1.75 vs edited ===== --- 1.75/net/ipv4/tcp_ipv4.c Tue Oct 28 20:10:47 2003 +++ edited/net/ipv4/tcp_ipv4.c Sat Nov 1 19:36:45 2003 @@ -187,7 +187,7 @@ sk_for_each_bound(sk2, node, &tb->owners) { if (sk != sk2 && - !ipv6_only_sock(sk2) && + !tcp_v6_ipv6only(sk2) && (!sk->sk_bound_dev_if || !sk2->sk_bound_dev_if || sk->sk_bound_dev_if == sk2->sk_bound_dev_if)) { -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From daniel.blueman@gmx.net Sat Nov 1 10:13:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 10:14:08 -0800 (PST) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA1IDX25019208 for ; Sat, 1 Nov 2003 10:13:34 -0800 Received: (qmail 13073 invoked by uid 0); 1 Nov 2003 18:13:27 -0000 Received: from 81.107.229.142 by www6.gmx.net with HTTP; Sat, 1 Nov 2003 19:13:27 +0100 (MET) Date: Sat, 1 Nov 2003 19:13:27 +0100 (MET) From: "Daniel Blueman" To: "David S. Miller" Cc: devik@cdi.cz, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org MIME-Version: 1.0 References: <20031030130859.605f856d.davem@redhat.com> Subject: Re: [2.6.0-test9] QoS HTB crash... X-Priority: 3 (Normal) X-Authenticated: #8973862 Message-ID: <4371.1067710407@www6.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-archive-position: 1167 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: daniel.blueman@gmx.net Precedence: bulk X-list: netdev Having applied this patch, I still get this issue when I kill pppd: Oops: 0002 [#1] CPU: 0 >>EIP; c02ced99 <===== >>ebx; d9c0586c <_end+19797f60/3fb906f4> >>ecx; dc95adf8 <_end+1c4ed4ec/3fb906f4> >>edx; d9c057f8 <_end+19797eec/3fb906f4> >>esi; dc95adf8 <_end+1c4ed4ec/3fb906f4> >>edi; df4eceac <_end+1f07f5a0/3fb906f4> >>ebp; d9c4bdfc <_end+197de4f0/3fb906f4> >>esp; d9c4bde4 <_end+197de4d8/3fb906f4> Trace; c011a647 Trace; c02d3876 Trace; c02d3b1f Trace; c02d3b5e Trace; c011a647 Trace; c02d3cc4 Trace; c02ce073 Trace; c02cdedc Trace; c02ce112 Trace; c02c1ea9 Trace; c02c260a Trace; c01398e8 Trace; c02b59e2 Trace; c02bd6ce Trace; c0235f8c Trace; c023c1ce Trace; c0183836 Trace; c016527c <__fput+7c/cd> Trace; c02363a5 Trace; c01652bb <__fput+bb/cd> Trace; c0163353 Trace; c0163481 Trace; c010a3eb Code; c02ced99 00000000 <_EIP>: Code; c02ced99 <===== 0: 83 ae 58 01 00 00 01 subl $0x1,0x158(%esi) <===== Code; c02ceda0 7: 8b 5d f8 mov 0xfffffff8(%ebp),%ebx Code; c02ceda3 a: 8b 75 fc mov 0xfffffffc(%ebp),%esi Code; c02ceda6 d: 89 ec mov %ebp,%esp Code; c02ceda8 f: 5d pop %ebp Code; c02ceda9 10: c3 ret Code; c02cedaa 11: 83 ab 3c 00 00 00 00 subl $0x0,0x3c(%ebx) <0>Kernel panic: Fatal exception in interrupt --- > On Thu, 30 Oct 2003 20:50:16 +0100 (CET) > devik wrote: > > > thanks for the report. I know that there is an issue regarding > > HTB in 2.6.x. Please send me net/sched/sch_htb.o, > > net/sched/sch_htb.c (just to be sure) and be sure that you > > build the kernel with debugging symbols (see debugging section > > of menuconfig/xconfig). > > I think the problem is the changes that were made > in 2.5.x to htb_next_rb_node(). It used to be: > > static void htb_next_rb_node(rb_node_t **n) > { > rb_node_t *p; > if ((*n)->rb_right) { > /* child at right. use it or its leftmost ancestor */ > *n = (*n)->rb_right; > while ((*n)->rb_left) > *n = (*n)->rb_left; > return; > } > while ((p = (*n)->rb_parent) != NULL) { > /* if we've arrived from left child then we have next node > */ > if (p->rb_left == *n) break; > *n = p; > } > *n = p; > } > > But it was changed into: > > static void htb_next_rb_node(struct rb_node **n) > { > *n = rb_next(*n); > } > > This is wrong, the new code has much different side effects > than the original code. > > This looks like the problem, devik what do you think? > -- Daniel J Blueman NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ From akpm@osdl.org Sat Nov 1 13:34:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 13:34:55 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA1LXu25023712 for ; Sat, 1 Nov 2003 13:34:16 -0800 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id hA1LXhC16609; Sat, 1 Nov 2003 13:33:46 -0800 Date: Sat, 1 Nov 2003 13:36:01 -0800 From: Andrew Morton To: Stian Jordet Cc: netdev@oss.sgi.com Subject: Re: Oops at "NET: Registering protocol family 23" at boot with 2.6.0t9-bk Message-Id: <20031101133601.7cf12497.akpm@osdl.org> In-Reply-To: <1067705386.666.1.camel@chevrolet.hybel> References: <1067705386.666.1.camel@chevrolet.hybel> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1168 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Stian Jordet wrote: > > Hello, > kernel 2.6.0-test9 works perfect here, but with the latest cset I get > the attached oops at boottime. Hope this helps someone. > Please send your .config. > NET: Registered protocol family 23 > Unable to handle kernel NULL pointer dereference at virtual address 00000004 > printing eip: > c03de40d > *pde = 00000000 > Oops: 0002 [#1] > CPU: 0 > CIP: 0060:[] Not tainted > EFLAGS: 00010202 > EIP is at dev_add_pack+0x4d/0xb0 > eax: 00000038 ebx: c062f2f8 ecx: 00000000 edx: c05799e0 > esi: c05799d0 edi: 00000000 ebp: 00000000 esp: c152ffb4 > ds: 007b es: 007b ss: 0068 > Process swapper (pid: 1, threadinfo=c152e000 task=dff8f900) > Stack: c05e7fc8 00000001 c05defad c05799d0 c04af833 c05c094c 00000000 00000000 > c01359af 00000000 c152e000 c01050f6 00000002 c01050a0 00000000 c01072b9 > 00000000 00000000 00000000 > Call Trace: > [] irda_init+0x3d/0x60 > [] do_initcalls+0x2c/0xa0 > [] init_workqueues+0xf/0x24 > [] init+0x56/0x180 > [] init+0x0/0x180 > [] kernel_thread_helper+0x5/0xc > > Code: 89 51 04 89 90 c0 f2 62 c0 c6 05 40 3c 57 c0 01 b8 00 e0 ff > (0)Kernel panic: Fatal exception in interrupt > In interrupt handler - not syncing > > > From liste@jordet.nu Sat Nov 1 13:54:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 13:54:51 -0800 (PST) Received: from dodge.hybel (root@dodge.jordet.nu [217.13.8.142]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA1Lro25024174 for ; Sat, 1 Nov 2003 13:54:11 -0800 Received: from chevrolet.hybel (stianj@chevrolet.hybel [192.168.0.2]) by dodge.hybel (8.12.3/8.12.3/Debian-6.6) with ESMTP id hA1LreuY024928 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 1 Nov 2003 22:53:41 +0100 Subject: Re: Oops at "NET: Registering protocol family 23" at boot with 2.6.0t9-bk From: Stian Jordet To: Andrew Morton Cc: netdev@oss.sgi.com In-Reply-To: <20031101133601.7cf12497.akpm@osdl.org> References: <1067705386.666.1.camel@chevrolet.hybel> <20031101133601.7cf12497.akpm@osdl.org> Content-Type: multipart/mixed; boundary="=-CXZmLYdmid/PKgG6qYdK" Message-Id: <1067723628.643.0.camel@chevrolet.hybel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 01 Nov 2003 22:53:48 +0100 X-archive-position: 1169 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: liste@jordet.nu Precedence: bulk X-list: netdev --=-CXZmLYdmid/PKgG6qYdK Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dodge.hybel id hA1LreuY024928 l=F8r, 01.11.2003 kl. 22.36 skrev Andrew Morton: > Stian Jordet wrote: > > > > Hello, > > kernel 2.6.0-test9 works perfect here, but with the latest cset I get > > the attached oops at boottime. Hope this helps someone. > >=20 >=20 > Please send your .config. Here you are :) Thanks for looking into this :) Best regards, Stian > > NET: Registered protocol family 23 > > Unable to handle kernel NULL pointer dereference at virtual address 0= 0000004 > > printing eip: > > c03de40d > > *pde =3D 00000000 > > Oops: 0002 [#1] > > CPU: 0 > > CIP: 0060:[] Not tainted > > EFLAGS: 00010202 > > EIP is at dev_add_pack+0x4d/0xb0 > > eax: 00000038 ebx: c062f2f8 ecx: 00000000 edx: c05799e0 > > esi: c05799d0 edi: 00000000 ebp: 00000000 esp: c152ffb4 > > ds: 007b es: 007b ss: 0068 > > Process swapper (pid: 1, threadinfo=3Dc152e000 task=3Ddff8f900) > > Stack: c05e7fc8 00000001 c05defad c05799d0 c04af833 c05c094c 00000000= 00000000 > > c01359af 00000000 c152e000 c01050f6 00000002 c01050a0 00000000= c01072b9 > > 00000000 00000000 00000000 > > Call Trace: > > [] irda_init+0x3d/0x60 > > [] do_initcalls+0x2c/0xa0 > > [] init_workqueues+0xf/0x24 > > [] init+0x56/0x180 > > [] init+0x0/0x180 > > [] kernel_thread_helper+0x5/0xc > > =20 > > Code: 89 51 04 89 90 c0 f2 62 c0 c6 05 40 3c 57 c0 01 b8 00 e0 ff > > (0)Kernel panic: Fatal exception in interrupt > > In interrupt handler - not syncing > > =20 > >=20 > >=20 --=-CXZmLYdmid/PKgG6qYdK Content-Disposition: attachment; filename=config-2.6.0-test9 Content-Type: text/plain; name=config-2.6.0-test9; charset=iso-8859-1 Content-Transfer-Encoding: 7bit # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_CLEAN_COMPILE is not set CONFIG_STANDALONE=y CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MELAN is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_HPET_TIMER is not set # CONFIG_HPET_EMULATE_RTC is not set CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_PREEMPT=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # CONFIG_EDD is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_HAVE_DEC_LOCK=y # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_SOFTWARE_SUSPEND=y # CONFIG_PM_DISK is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y # CONFIG_ACPI_FAN is not set CONFIG_ACPI_PROCESSOR=y # CONFIG_ACPI_THERMAL is not set # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_ACPI_RELAXED_AML is not set # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y # CONFIG_PCI_LEGACY_PROC is not set CONFIG_PCI_NAMES=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # CONFIG_PCMCIA=y CONFIG_YENTA=y CONFIG_CARDBUS=y # CONFIG_I82092 is not set # CONFIG_TCIC is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_MISC=y # # Device Drivers # # # Generic Driver Options # # CONFIG_FW_LOADER is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_PC_CML1=y # CONFIG_PARPORT_SERIAL is not set # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_PC_PCMCIA is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # # CONFIG_ISAPNP is not set CONFIG_PNPBIOS=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_LBD is not set # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_IDEDISK_STROKE is not set CONFIG_BLK_DEV_IDECS=y # CONFIG_BLK_DEV_IDECD is not set # CONFIG_BLK_DEV_IDETAPE is not set CONFIG_BLK_DEV_IDEFLOPPY=y # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set # CONFIG_IDE_TASKFILE_IO is not set # # IDE chipset support/bugfixes # # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_IDEPNP is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_GENERIC is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDE_TCQ is not set # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set # CONFIG_IDEDMA_PCI_WIP is not set CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_DMA_NONPCI is not set # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=y # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=y # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_REPORT_LUNS is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=253 CONFIG_AIC7XXX_RESET_DELAY_MS=5000 # CONFIG_AIC7XXX_PROBE_EISA_VL is not set # CONFIG_AIC7XXX_BUILD_FIRMWARE is not set # CONFIG_AIC7XXX_DEBUG_ENABLE is not set CONFIG_AIC7XXX_DEBUG_MASK=0 # CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_MEGARAID is not set # CONFIG_SCSI_SATA is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # PCMCIA SCSI adapter support # # CONFIG_PCMCIA_AHA152X is not set # CONFIG_PCMCIA_FDOMAIN is not set # CONFIG_PCMCIA_NINJA_SCSI is not set # CONFIG_PCMCIA_QLOGIC is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK_DEV is not set CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set # CONFIG_IPV6 is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_FTP=y CONFIG_IP_NF_IRC=y # CONFIG_IP_NF_TFTP is not set # CONFIG_IP_NF_AMANDA is not set CONFIG_IP_NF_QUEUE=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=y # CONFIG_IP_NF_MATCH_IPRANGE is not set CONFIG_IP_NF_MATCH_MAC=y CONFIG_IP_NF_MATCH_PKTTYPE=y CONFIG_IP_NF_MATCH_MARK=y CONFIG_IP_NF_MATCH_MULTIPORT=y CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_RECENT=y CONFIG_IP_NF_MATCH_ECN=y CONFIG_IP_NF_MATCH_DSCP=y CONFIG_IP_NF_MATCH_AH_ESP=y CONFIG_IP_NF_MATCH_LENGTH=y CONFIG_IP_NF_MATCH_TTL=y CONFIG_IP_NF_MATCH_TCPMSS=y CONFIG_IP_NF_MATCH_HELPER=y CONFIG_IP_NF_MATCH_STATE=y CONFIG_IP_NF_MATCH_CONNTRACK=y CONFIG_IP_NF_MATCH_OWNER=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_IP_NF_TARGET_REDIRECT=y # CONFIG_IP_NF_TARGET_NETMAP is not set # CONFIG_IP_NF_TARGET_SAME is not set CONFIG_IP_NF_NAT_LOCAL=y CONFIG_IP_NF_NAT_SNMP_BASIC=y CONFIG_IP_NF_NAT_IRC=y CONFIG_IP_NF_NAT_FTP=y CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_TARGET_TOS=y CONFIG_IP_NF_TARGET_ECN=y CONFIG_IP_NF_TARGET_DSCP=y CONFIG_IP_NF_TARGET_MARK=y # CONFIG_IP_NF_TARGET_CLASSIFY is not set CONFIG_IP_NF_TARGET_LOG=y CONFIG_IP_NF_TARGET_ULOG=y CONFIG_IP_NF_TARGET_TCPMSS=y CONFIG_IP_NF_ARPTABLES=y # CONFIG_IP_NF_ARPFILTER is not set CONFIG_IP_NF_ARP_MANGLE=y # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IPV6_SCTP__=y # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_MII is not set # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_HP100 is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_B44 is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set CONFIG_E100=y # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=y CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=y CONFIG_PPP_SYNC_TTY=y CONFIG_PPP_DEFLATE=y CONFIG_PPP_BSDCOMP=y # CONFIG_PPPOE is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # PCMCIA network device support # CONFIG_NET_PCMCIA=y # CONFIG_PCMCIA_3C589 is not set # CONFIG_PCMCIA_3C574 is not set # CONFIG_PCMCIA_FMVJ18X is not set CONFIG_PCMCIA_PCNET=y # CONFIG_PCMCIA_NMCLAN is not set # CONFIG_PCMCIA_SMC91C92 is not set # CONFIG_PCMCIA_XIRC2PS is not set # CONFIG_PCMCIA_AXNET is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # CONFIG_IRDA=y # # IrDA protocols # # CONFIG_IRLAN is not set # CONFIG_IRNET is not set CONFIG_IRCOMM=y # CONFIG_IRDA_ULTRA is not set # # IrDA options # CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_FAST_RR=y CONFIG_IRDA_DEBUG=y # # Infrared-port device drivers # # # SIR device drivers # CONFIG_IRTTY_SIR=y # # Dongle support # # CONFIG_DONGLE is not set # # Old SIR device drivers # # CONFIG_IRPORT_SIR is not set # # Old Serial dongle support # # # FIR device drivers # # CONFIG_USB_IRDA is not set # CONFIG_TOSHIBA_FIR is not set # CONFIG_VLSI_FIR is not set # # Bluetooth support # CONFIG_BT=y CONFIG_BT_L2CAP=y CONFIG_BT_SCO=y CONFIG_BT_RFCOMM=y CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=y CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y # # Bluetooth device drivers # CONFIG_BT_HCIUSB=m # CONFIG_BT_USB_SCO is not set # CONFIG_BT_USB_ZERO_PACKET is not set # CONFIG_BT_HCIUART is not set # CONFIG_BT_HCIDTL1 is not set # CONFIG_BT_HCIBT3C is not set # CONFIG_BT_HCIBLUECARD is not set # CONFIG_BT_HCIBTUART is not set # CONFIG_BT_HCIVHCI is not set # # ISDN subsystem # # CONFIG_ISDN_BOOL is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # CONFIG_GAMEPORT=y CONFIG_SOUND_GAMEPORT=y # CONFIG_GAMEPORT_NS558 is not set # CONFIG_GAMEPORT_L4 is not set CONFIG_GAMEPORT_EMU10K1=y # CONFIG_GAMEPORT_VORTEX is not set # CONFIG_GAMEPORT_FM801 is not set # CONFIG_GAMEPORT_CS461x is not set CONFIG_SERIO=y CONFIG_SERIO_I8042=y # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y # CONFIG_MOUSE_PS2_SYNAPTICS is not set # CONFIG_MOUSE_SERIAL is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=y # CONFIG_INPUT_UINPUT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y # CONFIG_SERIAL_8250_CONSOLE is not set # CONFIG_SERIAL_8250_CS is not set # CONFIG_SERIAL_8250_ACPI is not set CONFIG_SERIAL_8250_NR_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # CONFIG_PRINTER is not set # CONFIG_PPDEV is not set # CONFIG_TIPAR is not set # # I2C support # CONFIG_I2C=y # CONFIG_I2C_CHARDEV is not set # # I2C Algorithms # # CONFIG_I2C_ALGOBIT is not set # CONFIG_I2C_ALGOPCF is not set # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set CONFIG_I2C_VIAPRO=y # # I2C Hardware Sensors Chip support # CONFIG_I2C_SENSOR=y # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_EEPROM is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_VIA686A is not set CONFIG_SENSORS_W83781D=y # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_QIC02_TAPE is not set # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_HW_RANDOM is not set CONFIG_NVRAM=y CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=m # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set # CONFIG_AGP_INTEL is not set # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set CONFIG_AGP_VIA=m # CONFIG_DRM is not set # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set # CONFIG_HANGCHECK_TIMER is not set # # Multimedia devices # CONFIG_VIDEO_DEV=y # # Video For Linux # # # Video Adapters # # CONFIG_VIDEO_BWQCAM is not set # CONFIG_VIDEO_CQCAM is not set # CONFIG_VIDEO_W9966 is not set # CONFIG_VIDEO_CPIA is not set # CONFIG_VIDEO_SAA5249 is not set # CONFIG_TUNER_3036 is not set # CONFIG_VIDEO_STRADIS is not set # CONFIG_VIDEO_ZORAN is not set # CONFIG_VIDEO_ZR36120 is not set CONFIG_VIDEO_SAA7134=y # CONFIG_VIDEO_MXB is not set # CONFIG_VIDEO_DPC is not set # CONFIG_VIDEO_HEXIUM_ORION is not set # CONFIG_VIDEO_HEXIUM_GEMINI is not set # # Radio Adapters # # CONFIG_RADIO_GEMTEK_PCI is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set CONFIG_VIDEO_TUNER=y CONFIG_VIDEO_BUF=y # CONFIG_VIDEO_BTCX is not set # # Graphics support # CONFIG_FB=y # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set CONFIG_FB_VESA=y CONFIG_VIDEO_SELECT=y # CONFIG_FB_HGA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_MATROX is not set CONFIG_FB_RADEON=y # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=m CONFIG_PCI_CONSOLE=y # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # # Logo configuration # CONFIG_LOGO=y # CONFIG_LOGO_LINUX_MONO is not set # CONFIG_LOGO_LINUX_VGA16 is not set CONFIG_LOGO_LINUX_CLUT224=y # # Sound # CONFIG_SOUND=y # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_SEQUENCER=m # CONFIG_SND_SEQ_DUMMY is not set CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # # CONFIG_SND_DUMMY is not set # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set CONFIG_SND_MPU401=m # # PCI devices # # CONFIG_SND_ALI5451 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS4281 is not set CONFIG_SND_EMU10K1=m # CONFIG_SND_KORG1212 is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VX222 is not set # # ALSA USB devices # # CONFIG_SND_USB_AUDIO is not set # # PCMCIA devices # # CONFIG_SND_VXPOCKET is not set # CONFIG_SND_VXP440 is not set # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # USB support # CONFIG_USB=y # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # # USB Host Controller Drivers # # CONFIG_USB_EHCI_HCD is not set # CONFIG_USB_OHCI_HCD is not set CONFIG_USB_UHCI_HCD=y # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # # USB Bluetooth TTY can only be used with disabled Bluetooth subsystem # # CONFIG_USB_MIDI is not set # CONFIG_USB_ACM is not set CONFIG_USB_PRINTER=y CONFIG_USB_STORAGE=y # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_HP8200e is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # # USB Human Interface Devices (HID) # CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_XPAD is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set CONFIG_USB_SCANNER=y # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # CONFIG_USB_VICAM is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_KONICAWC is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_PWC is not set # CONFIG_USB_SE401 is not set # CONFIG_USB_STV680 is not set # # USB Network adaptors # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # # USB port drivers # # CONFIG_USB_USS720 is not set # # USB Serial Converter support # CONFIG_USB_SERIAL=m # CONFIG_USB_SERIAL_GENERIC is not set # CONFIG_USB_SERIAL_BELKIN is not set # CONFIG_USB_SERIAL_WHITEHEAT is not set # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set # CONFIG_USB_SERIAL_EMPEG is not set # CONFIG_USB_SERIAL_FTDI_SIO is not set # CONFIG_USB_SERIAL_VISOR is not set # CONFIG_USB_SERIAL_IPAQ is not set # CONFIG_USB_SERIAL_IR is not set # CONFIG_USB_SERIAL_EDGEPORT is not set # CONFIG_USB_SERIAL_EDGEPORT_TI is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set # CONFIG_USB_SERIAL_KEYSPAN is not set # CONFIG_USB_SERIAL_KLSI is not set # CONFIG_USB_SERIAL_KOBIL_SCT is not set # CONFIG_USB_SERIAL_MCT_U232 is not set CONFIG_USB_SERIAL_PL2303=m # CONFIG_USB_SERIAL_SAFE is not set # CONFIG_USB_SERIAL_CYBERJACK is not set # CONFIG_USB_SERIAL_XIRCOM is not set # CONFIG_USB_SERIAL_OMNINET is not set # # USB Miscellaneous drivers # # CONFIG_USB_TIGL is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_BRLVGER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_TEST is not set # CONFIG_USB_GADGET is not set # # File systems # CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set CONFIG_XFS_QUOTA=y CONFIG_XFS_POSIX_ACL=y # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_QUOTA=y # CONFIG_QFMT_V1 is not set # CONFIG_QFMT_V2 is not set CONFIG_QUOTACTL=y # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=y CONFIG_UDF_FS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_NTFS_FS=y # CONFIG_NTFS_DEBUG is not set # CONFIG_NTFS_RW is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y # CONFIG_DEVFS_FS is not set CONFIG_DEVPTS_FS=y # CONFIG_DEVPTS_FS_XATTR is not set CONFIG_TMPFS=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V4=y # CONFIG_NFS_DIRECTIO is not set # CONFIG_NFSD is not set CONFIG_LOCKD=y CONFIG_LOCKD_V4=y # CONFIG_EXPORTFS is not set CONFIG_SUNRPC=y # CONFIG_SUNRPC_GSS is not set CONFIG_SMB_FS=y # CONFIG_SMB_NLS_DEFAULT is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_SMB_NLS=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-15" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=y # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set CONFIG_NLS_CODEPAGE_865=y # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=y # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=y # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_IOVIRT is not set # CONFIG_MAGIC_SYSRQ is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_FRAME_POINTER is not set CONFIG_X86_EXTRA_IRQS=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # # CONFIG_SECURITY is not set # # Cryptographic options # # CONFIG_CRYPTO is not set # # Library routines # CONFIG_CRC32=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_PC=y --=-CXZmLYdmid/PKgG6qYdK-- From akpm@osdl.org Sat Nov 1 16:01:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 16:02:35 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA201d25026191 for ; Sat, 1 Nov 2003 16:01:59 -0800 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id hA201VC01085; Sat, 1 Nov 2003 16:01:31 -0800 Date: Sat, 1 Nov 2003 16:03:50 -0800 From: Andrew Morton To: Stian Jordet Cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: Oops at "NET: Registering protocol family 23" at boot with 2.6.0t9-bk Message-Id: <20031101160350.2f1fe0af.akpm@osdl.org> In-Reply-To: <1067723628.643.0.camel@chevrolet.hybel> References: <1067705386.666.1.camel@chevrolet.hybel> <20031101133601.7cf12497.akpm@osdl.org> <1067723628.643.0.camel@chevrolet.hybel> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hA201d25026191 X-archive-position: 1170 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Stian Jordet wrote: > > lør, 01.11.2003 kl. 22.36 skrev Andrew Morton: > > Stian Jordet wrote: > > > > > > Hello, > > > kernel 2.6.0-test9 works perfect here, but with the latest cset I get > > > the attached oops at boottime. Hope this helps someone. > > > > > > > Please send your .config. > > Here you are :) Thanks for looking into this :) OK, it goes bang because ptype_all has not been initialised yet. This is because net_dev_init() is fs_initcall, and irda_init() is subsys_initcall - irda_init() runs before net_dev_init(). Dave, I'm not sure what's the best thing to do here - I was afraid that the initcall level shuffling was a bit premature. IRDA doesn't look flexible (hugs to JT for commenting this nicely): /* * The IrDA stack must be initialised *before* drivers get initialised, * and *before* higher protocols (IrLAN/IrCOMM/IrNET) get initialised, * otherwise bad things will happen (hashbins will be NULL for example). * Those modules are at module_init()/device_initcall() level. * * On the other hand, it needs to be initialised *after* the basic * networking, the /proc/net filesystem and sysctl module. Those are * currently initialised in .../init/main.c (before initcalls). * Also, IrDA drivers needs to be initialised *after* the random number * generator (main stack and higher layer init don't need it anymore). * * Jean II */ So I dunno. Maybe we need to just revert the PNP patch, think about it some more? diff -puN drivers/pnp/isapnp/core.c~pnp-initcall-revert drivers/pnp/isapnp/core.c --- 25/drivers/pnp/isapnp/core.c~pnp-initcall-revert 2003-11-01 16:02:36.000000000 -0800 +++ 25-akpm/drivers/pnp/isapnp/core.c 2003-11-01 16:02:54.000000000 -0800 @@ -1160,7 +1160,7 @@ int __init isapnp_init(void) return 0; } -fs_initcall(isapnp_init); +device_initcall(isapnp_init); /* format is: noisapnp */ diff -puN net/core/dev.c~pnp-initcall-revert net/core/dev.c --- 25/net/core/dev.c~pnp-initcall-revert 2003-11-01 16:02:36.000000000 -0800 +++ 25-akpm/net/core/dev.c 2003-11-01 16:02:54.000000000 -0800 @@ -3067,7 +3067,7 @@ out: return rc; } -fs_initcall(net_dev_init); +subsys_initcall(net_dev_init); EXPORT_SYMBOL(__dev_get); EXPORT_SYMBOL(__dev_get_by_flags); _ From acme@conectiva.com.br Sat Nov 1 17:15:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 17:16:25 -0800 (PST) Received: from oops.kerneljanitors.org (1-131.ctame700-6.telepar.net.br [200.193.158.131]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA21FJ25030573 for ; Sat, 1 Nov 2003 17:15:39 -0800 Received: by oops.kerneljanitors.org (Postfix, from userid 500) id 093F81966F; Sun, 2 Nov 2003 00:49:23 +0000 (UTC) Date: Sat, 1 Nov 2003 22:49:23 -0200 From: Arnaldo Carvalho de Melo To: "David S. Miller" Cc: Linux Networking Development Mailing List Subject: [PATCH] LLC: fix client side after sockaddr_llc fixup Message-ID: <20031102004923.GB11632@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.4i X-archive-position: 1171 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Hi David, After I did the fixup in struct sockaddr_llc, i.e. not to use 3 addresses, but just one the server side was OK, as I said to you in that RFC, but the client side was working by luck, i.e. it was always getting the destination sap and using it as both local and destination sap, this was because llc_ui_autobind was OK for servers and clients in the past with 3 addresses, but now it can't be shared by PF_LLC->bind() and PF_LLC->{sendmsg, connect}, so I made ->bind() have its own specific autobinding code and llc_ui_autobind is now only used by ->connect() and ->sendmsg(). This makes the client able to make multiple connections to the same sap on another machine. I refrained from changing the comments in llc_ui_bind and llc_ui_autobind to make the hunks in this patch look sane, will submit another patch that updates the comments to the (now) correct behaviour. Tested running sshd server with PF_LLC patch on both machines and connecting back and forth several times, everything working fine now. Best Regards, - Arnaldo ===== net/llc/af_llc.c 1.57 vs edited ===== --- 1.57/net/llc/af_llc.c Thu Oct 30 16:35:41 2003 +++ edited/net/llc/af_llc.c Sat Nov 1 21:36:53 2003 @@ -250,41 +250,19 @@ if (!sk->sk_zapped) goto out; - /* bind to a specific sap, optional. */ - if (!addr->sllc_sap) { - rc = -EUSERS; - addr->sllc_sap = llc_ui_autoport(); - if (!addr->sllc_sap) - goto out; - } - sap = llc_sap_find(addr->sllc_sap); - if (!sap) { - sap = llc_sap_open(addr->sllc_sap, NULL); - rc = -EBUSY; /* some other network layer is using the sap */ - if (!sap) - goto out; - } else { - struct llc_addr laddr, daddr; - struct sock *ask; - - memset(&laddr, 0, sizeof(laddr)); - memset(&daddr, 0, sizeof(daddr)); - /* - * FIXME: check if the the address is multicast, - * only SOCK_DGRAM can do this. - */ - memcpy(laddr.mac, addr->sllc_mac, IFHWADDRLEN); - laddr.lsap = addr->sllc_sap; - rc = -EADDRINUSE; /* mac + sap clash. */ - ask = llc_lookup_established(sap, &daddr, &laddr); - if (ask) { - sock_put(ask); - goto out; - } - } - llc->laddr.lsap = addr->sllc_sap; - if (llc->dev) - memcpy(llc->laddr.mac, llc->dev->dev_addr, IFHWADDRLEN); + rc = -ENODEV; + llc->dev = dev_getfirstbyhwtype(addr->sllc_arphrd); + if (!llc->dev) + goto out; + rc = -EUSERS; + llc->laddr.lsap = llc_ui_autoport(); + if (!llc->laddr.lsap) + goto out; + rc = -EBUSY; /* some other network layer is using the sap */ + sap = llc_sap_open(llc->laddr.lsap, NULL); + if (!sap) + goto out; + memcpy(llc->laddr.mac, llc->dev->dev_addr, IFHWADDRLEN); memcpy(&llc->addr, addr, sizeof(llc->addr)); /* assign new connection to its SAP */ llc_sap_add_socket(sap, sk); @@ -315,6 +293,8 @@ { struct sockaddr_llc *addr = (struct sockaddr_llc *)uaddr; struct sock *sk = sock->sk; + struct llc_opt *llc = llc_sk(sk); + struct llc_sap *sap; int rc = -EINVAL; dprintk("%s: binding %02X\n", __FUNCTION__, addr->sllc_sap); @@ -323,8 +303,43 @@ rc = -EAFNOSUPPORT; if (addr->sllc_family != AF_LLC) goto out; - /* use autobind, to avoid code replication. */ - rc = llc_ui_autobind(sock, addr); + if (!addr->sllc_sap) { + rc = -EUSERS; + addr->sllc_sap = llc_ui_autoport(); + if (!addr->sllc_sap) + goto out; + } + sap = llc_sap_find(addr->sllc_sap); + if (!sap) { + sap = llc_sap_open(addr->sllc_sap, NULL); + rc = -EBUSY; /* some other network layer is using the sap */ + if (!sap) + goto out; + } else { + struct llc_addr laddr, daddr; + struct sock *ask; + + memset(&laddr, 0, sizeof(laddr)); + memset(&daddr, 0, sizeof(daddr)); + /* + * FIXME: check if the the address is multicast, + * only SOCK_DGRAM can do this. + */ + memcpy(laddr.mac, addr->sllc_mac, IFHWADDRLEN); + laddr.lsap = addr->sllc_sap; + rc = -EADDRINUSE; /* mac + sap clash. */ + ask = llc_lookup_established(sap, &daddr, &laddr); + if (ask) { + sock_put(ask); + goto out; + } + } + llc->laddr.lsap = addr->sllc_sap; + memcpy(llc->laddr.mac, addr->sllc_mac, IFHWADDRLEN); + memcpy(&llc->addr, addr, sizeof(llc->addr)); + /* assign new connection to its SAP */ + llc_sap_add_socket(sap, sk); + rc = sk->sk_zapped = 0; out: return rc; } @@ -399,15 +414,7 @@ llc->daddr.lsap = addr->sllc_sap; memcpy(llc->daddr.mac, addr->sllc_mac, IFHWADDRLEN); } - if (!llc->dev) { - rc = -ENODEV; - dev = dev_getfirstbyhwtype(addr->sllc_arphrd); - if (!dev) - goto out; - llc->dev = dev; - memcpy(llc->laddr.mac, llc->dev->dev_addr, IFHWADDRLEN); - } else - dev = llc->dev; + dev = llc->dev; if (sk->sk_type != SOCK_STREAM) goto out; rc = -EALREADY; @@ -610,7 +617,7 @@ int rc = -EOPNOTSUPP; dprintk("%s: accepting on %02X\n", __FUNCTION__, - llc_sk(sk)->addr.sllc_sap); + llc_sk(sk)->laddr.lsap); lock_sock(sk); if (sk->sk_type != SOCK_STREAM) goto out; @@ -622,7 +629,7 @@ if (rc) goto out; dprintk("%s: got a new connection on %02X\n", __FUNCTION__, - llc_sk(sk)->addr.sllc_sap); + llc_sk(sk)->laddr.lsap); skb = skb_dequeue(&sk->sk_receive_queue); rc = -EINVAL; if (!skb->sk) @@ -747,13 +754,7 @@ if (rc) goto release; } - if (!llc->dev) { - rc = -ENODEV; - dev = dev_getfirstbyhwtype(addr->sllc_arphrd); - if (!dev) - goto release; - } else - dev = llc->dev; + dev = llc->dev; hdrlen = dev->hard_header_len + llc_ui_header_len(sk, addr); size = hdrlen + len; if (size > dev->mtu) From davem@pizda.ninka.net Sat Nov 1 19:36:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 19:37:26 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA23ah25031937 for ; Sat, 1 Nov 2003 19:36:46 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id TAA17405; Sat, 1 Nov 2003 19:29:26 -0800 Date: Sat, 1 Nov 2003 19:29:26 -0800 From: "David S. Miller" To: Andrew Morton Cc: liste@jordet.nu, netdev@oss.sgi.com Subject: Re: Oops at "NET: Registering protocol family 23" at boot with 2.6.0t9-bk Message-Id: <20031101192926.3c7d516f.davem@redhat.com> In-Reply-To: <20031101160350.2f1fe0af.akpm@osdl.org> References: <1067705386.666.1.camel@chevrolet.hybel> <20031101133601.7cf12497.akpm@osdl.org> <1067723628.643.0.camel@chevrolet.hybel> <20031101160350.2f1fe0af.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1172 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 1 Nov 2003 16:03:50 -0800 Andrew Morton wrote: > OK, it goes bang because ptype_all has not been initialised yet. > > This is because net_dev_init() is fs_initcall, and irda_init() is > subsys_initcall - irda_init() runs before net_dev_init(). > > Dave, I'm not sure what's the best thing to do here - I was afraid that the > initcall level shuffling was a bit premature. Turns out my suspicions were correct afterall :-) If it's just ptype_all that it needs, why don't we just initialize that one list head at compile time? From akpm@osdl.org Sat Nov 1 19:49:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 19:50:10 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA23na25032405 for ; Sat, 1 Nov 2003 19:49:36 -0800 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id hA23nHC27507; Sat, 1 Nov 2003 19:49:17 -0800 Date: Sat, 1 Nov 2003 19:51:37 -0800 From: Andrew Morton To: "David S. Miller" Cc: liste@jordet.nu, netdev@oss.sgi.com Subject: Re: Oops at "NET: Registering protocol family 23" at boot with 2.6.0t9-bk Message-Id: <20031101195137.0b19784a.akpm@osdl.org> In-Reply-To: <20031101192926.3c7d516f.davem@redhat.com> References: <1067705386.666.1.camel@chevrolet.hybel> <20031101133601.7cf12497.akpm@osdl.org> <1067723628.643.0.camel@chevrolet.hybel> <20031101160350.2f1fe0af.akpm@osdl.org> <20031101192926.3c7d516f.davem@redhat.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1173 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev "David S. Miller" wrote: > > If it's just ptype_all that it needs, why don't we just initialize > that one list head at compile time? Pessimism, basically. I'm sure we could locally fix IRDA, but what other bugs has that initcall change introduced? From davem@pizda.ninka.net Sat Nov 1 19:52:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 19:52:44 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA23qA25032684 for ; Sat, 1 Nov 2003 19:52:11 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id TAA17446; Sat, 1 Nov 2003 19:44:53 -0800 Date: Sat, 1 Nov 2003 19:44:53 -0800 From: "David S. Miller" To: Andrew Morton Cc: liste@jordet.nu, netdev@oss.sgi.com Subject: Re: Oops at "NET: Registering protocol family 23" at boot with 2.6.0t9-bk Message-Id: <20031101194453.70cb8405.davem@redhat.com> In-Reply-To: <20031101195137.0b19784a.akpm@osdl.org> References: <1067705386.666.1.camel@chevrolet.hybel> <20031101133601.7cf12497.akpm@osdl.org> <1067723628.643.0.camel@chevrolet.hybel> <20031101160350.2f1fe0af.akpm@osdl.org> <20031101192926.3c7d516f.davem@redhat.com> <20031101195137.0b19784a.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1174 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 1 Nov 2003 19:51:37 -0800 Andrew Morton wrote: > "David S. Miller" wrote: > > > > If it's just ptype_all that it needs, why don't we just initialize > > that one list head at compile time? > > Pessimism, basically. I'm sure we could locally fix IRDA, but what > other bugs has that initcall change introduced? Okie dokie, I'll likely just revert it in my tree after I look this issue over a little more. From rusty@samba.org Sat Nov 1 22:23:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 22:24:20 -0800 (PST) Received: from lists.samba.org (dp.samba.org [66.70.73.150]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA26Nj25004319 for ; Sat, 1 Nov 2003 22:23:46 -0800 Received: by lists.samba.org (Postfix, from userid 590) id 8755A2C003; Sun, 2 Nov 2003 06:23:45 +0000 (GMT) From: Rusty Russell To: anton@samba.org, kuznet@ms2.inr.ac.ru, davem@redhat.com Cc: netdev@oss.sgi.com Subject: Flow cache uses unsigned long for cpu mask. Date: Sun, 02 Nov 2003 16:34:35 +1100 Message-Id: <20031102062345.8755A2C003@lists.samba.org> X-archive-position: 1175 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rusty@rustcorp.com.au Precedence: bulk X-list: netdev net/core/flow.c uses "unsigned long flow_cache_cpu_map": AFAICT this should be a cpumask_t. Just doing an unrelated audit... Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. From davem@pizda.ninka.net Sat Nov 1 22:58:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 22:58:42 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA26w925004868 for ; Sat, 1 Nov 2003 22:58:09 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id WAA17668; Sat, 1 Nov 2003 22:50:50 -0800 Date: Sat, 1 Nov 2003 22:50:50 -0800 From: "David S. Miller" To: Rusty Russell Cc: anton@samba.org, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: net/core/flow.c cpu handling? Message-Id: <20031101225050.4de96a8b.davem@redhat.com> In-Reply-To: <20031102062345.A472E2C0CD@lists.samba.org> References: <20031102062345.A472E2C0CD@lists.samba.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1176 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Very likely, the code is how it is in order to make the 2.4.x backport of this code and the 2.6.x version as similar as humanly possible. From rusty@samba.org Sat Nov 1 23:16:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 23:16:38 -0800 (PST) Received: from lists.samba.org (dp.samba.org [66.70.73.150]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA27Ft25005365 for ; Sat, 1 Nov 2003 23:15:55 -0800 Received: by lists.samba.org (Postfix, from userid 590) id A472E2C0CD; Sun, 2 Nov 2003 06:23:45 +0000 (GMT) From: Rusty Russell To: anton@samba.org, kuznet@ms2.inr.ac.ru, davem@redhat.com Cc: netdev@oss.sgi.com Subject: net/core/flow.c cpu handling? Date: Sun, 02 Nov 2003 17:22:55 +1100 Message-Id: <20031102062345.A472E2C0CD@lists.samba.org> X-archive-position: 1177 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rusty@rustcorp.com.au Precedence: bulk X-list: netdev Hi again, Is there something I'm missing, or wouldn't the code in net/core/flow.c be much simpler if: 1) flow_cache_cpu_prepare() were done for each possible cpu, not dynamically as they came up. 2) The cpucontrol lock is held in flow_cache_flush to guarantee that cpus don't go up and down. 3) The normal cpu_online_map were used instead of flow_cache_cpu_map. The patch below is untested, but if you can't see anything wrong with the approach, I'll test it. Cheers, Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. Name: Simplify CPU Handling in net/core/flow.c Author: Rusty Russell Status: Booted on 2.6.0-test9-bk6 D: The cpu handling in net/core/flow.c is flawed, because it uses an D: unsigned long instead of a cpumask_t. This replaces that code D: with a much simpler version which allocates for every possible CPU, D: (the same amount of work on most machines) and takes the cpucontrol D: semaphore when flushing. --- linux-2.6.0-test9-bk4/net/core/flow.c 2003-10-09 18:03:03.000000000 +1000 +++ working-2.6.0-test9-bk4-hotcpu-with-kthread/net/core/flow.c 2003-11-02 17:10:55.000000000 +1100 @@ -65,23 +65,18 @@ struct flow_flush_info { atomic_t cpuleft; - unsigned long cpumap; struct completion completion; }; static DEFINE_PER_CPU(struct tasklet_struct, flow_flush_tasklets) = { NULL }; #define flow_flush_tasklet(cpu) (&per_cpu(flow_flush_tasklets, cpu)) -static DECLARE_MUTEX(flow_cache_cpu_sem); -static unsigned long flow_cache_cpu_map; -static unsigned int flow_cache_cpu_count; - static void flow_cache_new_hashrnd(unsigned long arg) { int i; for (i = 0; i < NR_CPUS; i++) - if (test_bit(i, &flow_cache_cpu_map)) + if (cpu_possible(i)) flow_hash_rnd_recalc(i) = 1; flow_hash_rnd_timer.expires = jiffies + FLOW_HASH_RND_PERIOD; @@ -178,7 +173,9 @@ cpu = smp_processor_id(); fle = NULL; - if (!test_bit(cpu, &flow_cache_cpu_map)) + /* Packet really early in init? Making flow_cache_init a + * pre-smp initcall would solve this. --RR */ + if (!flow_table(cpu)) goto nocache; if (flow_hash_rnd_recalc(cpu)) @@ -277,9 +274,6 @@ struct tasklet_struct *tasklet; cpu = smp_processor_id(); - if (!test_bit(cpu, &info->cpumap)) - return; - tasklet = flow_flush_tasklet(cpu); tasklet->data = (unsigned long)info; tasklet_schedule(tasklet); @@ -288,29 +282,23 @@ void flow_cache_flush(void) { struct flow_flush_info info; - static DECLARE_MUTEX(flow_flush_sem); - - down(&flow_cache_cpu_sem); - info.cpumap = flow_cache_cpu_map; - atomic_set(&info.cpuleft, flow_cache_cpu_count); - up(&flow_cache_cpu_sem); + /* Don't want cpus going down or up during this, also protects + * against multiple callers. */ + down(&cpucontrol); + atomic_set(&info.cpuleft, num_online_cpus()); init_completion(&info.completion); - down(&flow_flush_sem); - local_bh_disable(); smp_call_function(flow_cache_flush_per_cpu, &info, 1, 0); - if (test_bit(smp_processor_id(), &info.cpumap)) - flow_cache_flush_tasklet((unsigned long)&info); + flow_cache_flush_tasklet((unsigned long)&info); local_bh_enable(); wait_for_completion(&info.completion); - - up(&flow_flush_sem); + up(&cpucontrol); } -static int __devinit flow_cache_cpu_prepare(int cpu) +static void __devinit flow_cache_cpu_prepare(int cpu) { struct tasklet_struct *tasklet; unsigned long order; @@ -323,9 +311,8 @@ flow_table(cpu) = (struct flow_cache_entry **) __get_free_pages(GFP_KERNEL, order); - if (!flow_table(cpu)) - return NOTIFY_BAD; + panic("NET: failed to allocate flow cache order %lu\n", order); memset(flow_table(cpu), 0, PAGE_SIZE << order); @@ -334,39 +321,8 @@ tasklet = flow_flush_tasklet(cpu); tasklet_init(tasklet, flow_cache_flush_tasklet, 0); - - return NOTIFY_OK; -} - -static int __devinit flow_cache_cpu_online(int cpu) -{ - down(&flow_cache_cpu_sem); - set_bit(cpu, &flow_cache_cpu_map); - flow_cache_cpu_count++; - up(&flow_cache_cpu_sem); - - return NOTIFY_OK; -} - -static int __devinit flow_cache_cpu_notify(struct notifier_block *self, - unsigned long action, void *hcpu) -{ - unsigned long cpu = (unsigned long)cpu; - switch (action) { - case CPU_UP_PREPARE: - return flow_cache_cpu_prepare(cpu); - break; - case CPU_ONLINE: - return flow_cache_cpu_online(cpu); - break; - } - return NOTIFY_OK; } -static struct notifier_block __devinitdata flow_cache_cpu_nb = { - .notifier_call = flow_cache_cpu_notify, -}; - static int __init flow_cache_init(void) { int i; @@ -388,15 +344,9 @@ flow_hash_rnd_timer.expires = jiffies + FLOW_HASH_RND_PERIOD; add_timer(&flow_hash_rnd_timer); - register_cpu_notifier(&flow_cache_cpu_nb); - for (i = 0; i < NR_CPUS; i++) { - if (!cpu_online(i)) - continue; - if (flow_cache_cpu_prepare(i) == NOTIFY_OK && - flow_cache_cpu_online(i) == NOTIFY_OK) - continue; - panic("NET: failed to initialise flow cache hash table\n"); - } + for (i = 0; i < NR_CPUS; i++) + if (cpu_possible(i)) + flow_cache_cpu_prepare(i); return 0; } From davem@pizda.ninka.net Sat Nov 1 23:16:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 23:17:18 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA27Gk25005390 for ; Sat, 1 Nov 2003 23:16:46 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA17715; Sat, 1 Nov 2003 23:09:21 -0800 Date: Sat, 1 Nov 2003 23:09:21 -0800 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPV{4,6}: Fix one more inappropriate use of inet6_sk()->ipv6only Message-Id: <20031101230921.285fc538.davem@redhat.com> In-Reply-To: <20031101.200132.55114465.yoshfuji@linux-ipv6.org> References: <20031101.200132.55114465.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1178 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Applied, thanks Yoshfuji. From davem@pizda.ninka.net Sat Nov 1 23:17:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 23:18:18 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA27Hm25005936 for ; Sat, 1 Nov 2003 23:17:48 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA17742; Sat, 1 Nov 2003 23:10:27 -0800 Date: Sat, 1 Nov 2003 23:10:27 -0800 From: "David S. Miller" To: Arnaldo Carvalho de Melo Cc: netdev@oss.sgi.com Subject: Re: [PATCH] LLC: fix procfs reading when there are saps without sockets Message-Id: <20031101231027.13d06c8c.davem@redhat.com> In-Reply-To: <20031101065504.GK3705@conectiva.com.br> References: <20031101065504.GK3705@conectiva.com.br> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1179 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Applied, thanks Arnaldo. From davem@pizda.ninka.net Sat Nov 1 23:19:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 23:19:33 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA27J125006307 for ; Sat, 1 Nov 2003 23:19:01 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA17774; Sat, 1 Nov 2003 23:11:42 -0800 Date: Sat, 1 Nov 2003 23:11:42 -0800 From: "David S. Miller" To: Arnaldo Carvalho de Melo Cc: netdev@oss.sgi.com Subject: Re: [PATCH] LLC: fix client side after sockaddr_llc fixup Message-Id: <20031101231142.2bec7e27.davem@redhat.com> In-Reply-To: <20031102004923.GB11632@conectiva.com.br> References: <20031102004923.GB11632@conectiva.com.br> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1180 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Applied, thanks Arnaldo. From laforge@gnumonks.org Sun Nov 2 06:48:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Nov 2003 06:49:33 -0800 (PST) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA2Emv25021878 for ; Sun, 2 Nov 2003 06:48:58 -0800 Received: from [192.168.200.2] (helo=sunbeam.gnumonks.org) by coruscant.gnumonks.org with esmtp (TLSv1:RC4-SHA:128) (Exim 4.22) id 1AGJXD-0003Tj-5x; Sun, 02 Nov 2003 15:48:55 +0100 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.22) id 1AGDiF-0001NH-5z; Sun, 02 Nov 2003 09:35:55 +0100 Date: Sun, 2 Nov 2003 09:35:55 +0100 From: Harald Welte To: Joseph Conlin Cc: netdev@oss.sgi.com, jrd@cc.usu.edu Subject: Re: Replace the Nagle Algorithm Message-ID: <20031102083555.GG1536@sunbeam.de.gnumonks.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ndw/alBWmZEhfcZ" Content-Disposition: inline In-Reply-To: X-Operating-system: Linux sunbeam 2.6.0-test5-nftest X-Date: Today is Setting Orange, the 13rd day of The Aftermath in the YOLD 3169 User-Agent: Mutt/1.5.4i X-Spam-Score: -6.7 (------) X-archive-position: 1181 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev --4ndw/alBWmZEhfcZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 20, 2003 at 12:58:19PM -0600, Joseph Conlin wrote: > I see in the archives and the code that I have looked at (2.4.22, > 2.6.0-test8) that the Minshall algorithm is being used to reduce the > effects of Nagle/delayed ACK interaction. I haven't seen any mention of > the following solution, proposed as an IETF draft RFC by Joe Doupnik > (jrd@cc.usu.edu). >=20 > http://netlab1.usu.edu/pub/misc/draft-doupnik-tcpimpl-nagle-mode-00.txt Interesting, but do you know why this has not been aprooved as RFC and never became more than a draft of the TCP implementation working group? --=20 - Harald Welte http://www.gnumonks.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --4ndw/alBWmZEhfcZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/pMHrXaXGVTD0i/8RAvh+AKCSFS3PebGTt/FCcSXclZP8gs0nxACfcbgh XBIxvcDguLxJdDpMKxyCAvc= =H46q -----END PGP SIGNATURE----- --4ndw/alBWmZEhfcZ-- From laforge@gnumonks.org Sun Nov 2 06:52:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Nov 2003 06:53:32 -0800 (PST) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA2Eqv25022248 for ; Sun, 2 Nov 2003 06:52:58 -0800 Received: from [192.168.200.2] (helo=sunbeam.gnumonks.org) by coruscant.gnumonks.org with esmtp (TLSv1:RC4-SHA:128) (Exim 4.22) id 1AGJXB-0003Sf-2B; Sun, 02 Nov 2003 15:48:53 +0100 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.22) id 1AGE8u-0001hB-CB; Sun, 02 Nov 2003 10:03:28 +0100 Date: Sun, 2 Nov 2003 10:03:28 +0100 From: Harald Welte To: Christian Cc: netdev@oss.sgi.com Subject: Re: ppc32 lockups with 2.6 (maybe network related) Message-ID: <20031102090328.GI1536@sunbeam.de.gnumonks.org> References: <3FA10C2E.1000205@g-house.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k9xkV0rc9XGsukaG" Content-Disposition: inline In-Reply-To: <3FA10C2E.1000205@g-house.de> X-Operating-system: Linux sunbeam 2.6.0-test5-nftest X-Date: Today is Setting Orange, the 13rd day of The Aftermath in the YOLD 3169 User-Agent: Mutt/1.5.4i X-Spam-Score: -6.7 (------) X-archive-position: 1182 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev --k9xkV0rc9XGsukaG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 30, 2003 at 02:03:42PM +0100, Christian wrote: >=20 > I am not subscribed to netdev@oss.sgi.com, please CC me. > i posted to LKML too, but followed an advise better posting to this list. Please consider mailing this to the linuxppc-dev list, since you have a ppc specific bug. > Thank you, > Christian. --=20 - Harald Welte http://www.gnumonks.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --k9xkV0rc9XGsukaG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/pMhgXaXGVTD0i/8RAs4NAJ0Q6fOTLM4QqehYkntKyP/ZOOJPxwCfaptc pdUrQwKH6ePphJ3MLBNjvas= =5L+m -----END PGP SIGNATURE----- --k9xkV0rc9XGsukaG-- From laforge@gnumonks.org Sun Nov 2 06:53:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Nov 2003 06:53:53 -0800 (PST) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA2ErI25022255 for ; Sun, 2 Nov 2003 06:53:19 -0800 Received: from [192.168.200.2] (helo=sunbeam.gnumonks.org) by coruscant.gnumonks.org with esmtp (TLSv1:RC4-SHA:128) (Exim 4.22) id 1AGJXC-0003Sf-SY; Sun, 02 Nov 2003 15:48:55 +0100 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.22) id 1AGE4B-0001dh-Bm; Sun, 02 Nov 2003 09:58:35 +0100 Date: Sun, 2 Nov 2003 09:58:35 +0100 From: Harald Welte To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] remove historic entries in Documentation/Changes Message-ID: <20031102085835.GH1536@sunbeam.de.gnumonks.org> References: <20031029.012202.105420248.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aF3LVLvitz/VQU3c" Content-Disposition: inline In-Reply-To: <20031029.012202.105420248.yoshfuji@linux-ipv6.org> X-Operating-system: Linux sunbeam 2.6.0-test5-nftest X-Date: Today is Setting Orange, the 13rd day of The Aftermath in the YOLD 3169 User-Agent: Mutt/1.5.4i X-Spam-Score: -6.2 (------) X-archive-position: 1183 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev --aF3LVLvitz/VQU3c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Yoshifuji! Please consider the following update for netfilter/iptables, instead of removing any reference to it. --- linux-old/Documentation/Changes 2003-09-29 21:20:11.000000000 +0200 +++ linux/Documentation/Changes 2003-11-02 09:56:09.000000000 +0100 @@ -237,13 +237,15 @@ General changes --------------- =20 -The IP firewalling and NAT code has been replaced again. The new -netfilter software (including ipfwadm and ipchains backwards- -compatible modules) is currently distributed separately. - If you have advanced network configuration needs, you should probably consider using the network tools from ip-route2. =20 +Packet Filter / NAT +------------------- +The packet filtering and NAT code uses the same tools like the previous 2.= 4.x +kernel series (iptables). It still includes backwards-compatibility modul= es +for 2.2.x-style ipchains and 2.0.x-style ipfwadm. + PPP --- =20 @@ -400,11 +402,9 @@ --------- o =20 -Netfilter ---------- -o -o -o +Iptables +-------- +o =20 Ip-route2 --------- --=20 - Harald Welte http://www.gnumonks.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --aF3LVLvitz/VQU3c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/pMc7XaXGVTD0i/8RAmDRAJ49qfDwKFF2UtCIjbkj/TietFzzeACePjPS EJbFH95MuNC4KJzCm4cm9ds= =Emx2 -----END PGP SIGNATURE----- --aF3LVLvitz/VQU3c-- From amir.noam@intel.com Sun Nov 2 06:54:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Nov 2003 06:54:40 -0800 (PST) Received: from petasus.isw.intel.com (petasus.isw.intel.com [192.55.37.196]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA2Es425022532 for ; Sun, 2 Nov 2003 06:54:05 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by petasus.isw.intel.com (8.11.6-20030918-01/8.11.6/d: solo.mc,v 1.56 2003/05/22 21:18:22 rfjohns1 Exp $) with ESMTP id hA2Erb313358 for ; Sun, 2 Nov 2003 14:53:37 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hA2EvAu03030 for ; Sun, 2 Nov 2003 14:57:10 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110216535409775 ; Sun, 02 Nov 2003 16:53:54 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.254.188]) by sun111.npdj.intel.com (8.12.9/8.12.9/MailSET/Hub) with ESMTP id hA2Eq9BN002967; Sun, 2 Nov 2003 16:52:12 +0200 (IST) Content-Type: text/plain; charset="iso-8859-1" From: Amir Noam To: "Jay Vosburgh" Subject: Re: [Bonding-devel] Re: [PATCH 2/10] [bonding 2.6] fix monitoring functions Date: Sun, 2 Nov 2003 16:53:51 +0200 User-Agent: KMail/1.4.3 Cc: "Jeff Garzik" , , , References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200311021653.51194.amir.noam@intel.com> X-archive-position: 1184 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev On Thursday 30 October 2003 07:12 pm, Jay Vosburgh wrote: > >However, the following patch that restores backward > > compatibility with old ifenslave is still needed for 2.6. I > > see that it's already been applied by David Miller to 2.4. > > I thought we were dropping the ancient > (SIOCDEVPRIVATE) backwards compatibility in 2.6. This patch restores compatibility with old ifenslave versions that still use the SIOCBONDSETHWADDR command, not necessarily the SIOCDEVPRIVATE ioctls, so this patch is definitely needed for now. If we really want to remove backward compatibility in 2.6 we should do it for all bonding commands and replace them with the new interface. The problem is, since 2.6 is in effect in code freeze I'm not sure if we can actually replace the bonding<->ifenslave interface at this time (as much as I'd like to do it). Jeff, David, We haven't heard from either one of you on this issue: We want to drop support for SIOCDEVPRIVATE in 2.6. As a side effect this will force users to upgrade their user land tools anyway, so we might as well use this opportunity to insert the new interface to replace the current one. (Obviously, it would be preferable for such a change to take effect before 2.6.0 is made final) What do you think about making changes to the 2.6 bonding that will force users to upgrade their ifenslave application? (this new ifenslave will be, of course, backward compatible with 2.4 bonding). For now, however, this patch that restores backward compatibility is still needed for 2.6. I've noticed I'd sent out the wrong patch before (on 2003/10/30), so here is the corrected patch. Sorry for the mix up. Amir diff -Naurp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Thu Oct 30 10:38:34 2003 +++ b/drivers/net/bonding/bond_main.c Sun Nov 2 15:14:21 2003 @@ -3047,6 +3047,10 @@ static int bond_ioctl(struct net_device case SIOCBONDRELEASE: ret = bond_release(master_dev, slave_dev); break; + case BOND_SETHWADDR_OLD: + case SIOCBONDSETHWADDR: + ret = bond_sethwaddr(master_dev, slave_dev); + break; case BOND_CHANGE_ACTIVE_OLD: case SIOCBONDCHANGEACTIVE: if (USES_PRIMARY(bond_mode)) { From amir.noam@intel.com Sun Nov 2 06:55:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Nov 2003 06:55:41 -0800 (PST) Received: from petasus.isw.intel.com (petasus.isw.intel.com [192.55.37.196]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA2EtP25025670 for ; Sun, 2 Nov 2003 06:55:26 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by petasus.isw.intel.com (8.11.6-20030918-01/8.11.6/d: solo.mc,v 1.56 2003/05/22 21:18:22 rfjohns1 Exp $) with ESMTP id hA2Esv313524 for ; Sun, 2 Nov 2003 14:54:58 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hA2EwVu03171 for ; Sun, 2 Nov 2003 14:58:31 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110216551532671 ; Sun, 02 Nov 2003 16:55:15 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.254.188]) by sun111.npdj.intel.com (8.12.9/8.12.9/MailSET/Hub) with ESMTP id hA2ErXBN002982; Sun, 2 Nov 2003 16:53:33 +0200 (IST) Content-Type: text/plain; charset="iso-8859-1" From: Amir Noam To: "Jay Vosburgh" , "David S. Miller" Subject: Re: [Bonding-devel] [PATCH] [bonding 2.4] fix creating/destroying the /proc/net/bonding dir Date: Sun, 2 Nov 2003 16:55:15 +0200 User-Agent: KMail/1.4.3 Cc: , , References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200311021655.15498.amir.noam@intel.com> X-archive-position: 1185 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev On Friday 31 October 2003 10:10 pm, Jay Vosburgh wrote: > Jeff, can you apply Amir's patch, as it seems to work > just fine except for this ignorable problem? I'll append the > patch below for your convenience. That patch also applies to 2.6 (after the "restore backward compatibility" patch) with an offset of one line per chunk. I've appended it here again, against 2.6, just in case you want it to apply cleanly with no warnings. Amir diff -Naurp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Sun Nov 2 15:06:08 2003 +++ b/drivers/net/bonding/bond_main.c Sun Nov 2 15:06:18 2003 @@ -3573,6 +3573,62 @@ static void bond_destroy_proc_info(struc bond->bond_proc_file = NULL; } } + +/* Create the bonding directory under /proc/net, if doesn't exist yet. + * Caller must hold rtnl_lock. + */ +static void bond_create_proc_dir(void) +{ + int len = strlen(DRV_NAME); + + for (bond_proc_dir = proc_net->subdir; bond_proc_dir; + bond_proc_dir = bond_proc_dir->next) { + if ((bond_proc_dir->namelen == len) && + !memcmp(bond_proc_dir->name, DRV_NAME, len)) { + break; + } + } + + if (!bond_proc_dir) { + bond_proc_dir = proc_mkdir(DRV_NAME, proc_net); + if (bond_proc_dir) { + bond_proc_dir->owner = THIS_MODULE; + } else { + printk(KERN_WARNING DRV_NAME + ": Warning: cannot create /proc/net/%s\n", + DRV_NAME); + } + } +} + +/* Destroy the bonding directory under /proc/net, if empty. + * Caller must hold rtnl_lock. + */ +static void bond_destroy_proc_dir(void) +{ + struct proc_dir_entry *de; + + if (!bond_proc_dir) { + return; + } + + /* verify that the /proc dir is empty */ + for (de = bond_proc_dir->subdir; de; de = de->next) { + /* ignore . and .. */ + if (*(de->name) != '.') { + break; + } + } + + if (de) { + if (bond_proc_dir->owner == THIS_MODULE) { + bond_proc_dir->owner = NULL; + } + } else { + remove_proc_entry(DRV_NAME, proc_net); + bond_proc_dir = NULL; + } +} #endif /* CONFIG_PROC_FS */ /* @@ -3828,6 +3884,9 @@ static struct notifier_block bond_netdev .notifier_call = bond_netdev_event, }; +/* De-initialize device specific data. + * Caller must hold rtnl_lock. + */ static inline void bond_deinit(struct net_device *dev) { struct bonding *bond = dev->priv; @@ -3839,6 +3898,9 @@ static inline void bond_deinit(struct ne #endif } +/* Unregister and free all bond devices. + * Caller must hold rtnl_lock. + */ static void bond_free_all(void) { struct bonding *bond, *nxt; @@ -3846,16 +3908,13 @@ static void bond_free_all(void) list_for_each_entry_safe(bond, nxt, &bond_dev_list, bond_list) { struct net_device *dev = bond->device; - unregister_netdev(dev); + unregister_netdevice(dev); bond_deinit(dev); free_netdev(dev); } #ifdef CONFIG_PROC_FS - if (bond_proc_dir) { - remove_proc_entry(DRV_NAME, proc_net); - bond_proc_dir = NULL; - } + bond_destroy_proc_dir(); #endif } @@ -4233,18 +4292,12 @@ static int __init bonding_init(void) primary = NULL; } + rtnl_lock(); + #ifdef CONFIG_PROC_FS - bond_proc_dir = proc_mkdir(DRV_NAME, proc_net); - if (bond_proc_dir == NULL) { - printk(KERN_WARNING - "bonding_init(): can not create /proc/net/" DRV_NAME); - } else { - bond_proc_dir->owner = THIS_MODULE; - } + bond_create_proc_dir(); #endif - rtnl_lock(); - err = 0; for (no = 0; no < max_bonds; no++) { struct net_device *dev; @@ -4287,18 +4340,21 @@ static int __init bonding_init(void) return 0; out_err: - rtnl_unlock(); - /* free and unregister all bonds that were successfully added */ bond_free_all(); + rtnl_unlock(); + return err; } static void __exit bonding_exit(void) { unregister_netdevice_notifier(&bond_netdev_notifier); + + rtnl_lock(); bond_free_all(); + rtnl_unlock(); } module_init(bonding_init); From pekkas@netcore.fi Sun Nov 2 23:26:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Nov 2003 23:27:25 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA37Qo25015900 for ; Sun, 2 Nov 2003 23:26:51 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA37QbT27984; Mon, 3 Nov 2003 09:26:37 +0200 Date: Mon, 3 Nov 2003 09:26:36 +0200 (EET) From: Pekka Savola To: David Woodhouse cc: netdev@oss.sgi.com Subject: Re: IPv6 on-link assumption considered harmful In-Reply-To: <1067615762.3423.264.camel@hades.cambridge.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1186 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev On Fri, 31 Oct 2003, David Woodhouse wrote: > On Thu, 2003-10-30 at 21:09 +0200, Pekka Savola wrote: > > Just to give a heads-up before this is finalized, to give people ability > > to prepare or comment prior to this process is formalized in the IETF. > > With corresponding changes to the route advertisement protocol as used > by radvd, so that routes can actually be advertised to autoconfigured > nodes? Or does that already exist and I just missed it when I was > looking? Do you mean: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt This has nothing to do with this subject (AFAICS), but one person just a couple of days ago asked about this and wanted to know whether anyone else is hacking this, and if not, whether he should go ahead. We gave (as radvd maintainers) a thumbs-up. If you're also interested in hacking this, contact me off-list, and I'll ask the other person whether he'd like to get some help.. (Obviously, the preferences will need support in the kernel too.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rusty@samba.org Mon Nov 3 02:28:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Nov 2003 02:29:04 -0800 (PST) Received: from lists.samba.org (dp.samba.org [66.70.73.150]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3ASU25023258 for ; Mon, 3 Nov 2003 02:28:31 -0800 Received: by lists.samba.org (Postfix, from userid 590) id E1C622C05E; Mon, 3 Nov 2003 10:28:29 +0000 (GMT) From: Rusty Russell To: "David S. Miller" Cc: anton@samba.org, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: net/core/flow.c cpu handling? In-reply-to: Your message of "Sat, 01 Nov 2003 22:50:50 -0800." <20031101225050.4de96a8b.davem@redhat.com> Date: Mon, 03 Nov 2003 21:26:40 +1100 Message-Id: <20031103102829.E1C622C05E@lists.samba.org> X-archive-position: 1187 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rusty@rustcorp.com.au Precedence: bulk X-list: netdev In message <20031101225050.4de96a8b.davem@redhat.com> you write: > > Very likely, the code is how it is in order to make the > 2.4.x backport of this code and the 2.6.x version as > similar as humanly possible. Hmm, AFAICT the patch I sent should be easier, not harder to backport. Anyway, I'm carrying the patch as part of the hotplug CPU patches: we can discuss it once 2.6.0 is out. Thanks, Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. From wensong@linux-vs.org Mon Nov 3 06:17:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Nov 2003 06:18:09 -0800 (PST) Received: from lb1.ctrip.com ([218.244.111.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3EHS25001438 for ; Mon, 3 Nov 2003 06:17:32 -0800 Received: from penguin.linux-vs.org ([211.136.74.13]) by lb1.ctrip.com (8.12.9/8.12.9) with ESMTP id hA3EH0MP024985 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 3 Nov 2003 22:17:11 +0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by penguin.linux-vs.org (8.12.8/8.12.8) with ESMTP id hA3EFl4L005800; Mon, 3 Nov 2003 22:15:48 +0800 Date: Mon, 3 Nov 2003 22:15:47 +0800 (CST) From: Wensong Zhang To: netdev@oss.sgi.com cc: "David S. Miller" , Julian Anastasov Subject: [2.4/2.6 PATCH] Cosmetic IP_VS_INFO fix Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463811584-2066790978-1067868947=:5797" X-archive-position: 1188 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wensong@linux-vs.org Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463811584-2066790978-1067868947=:5797 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Here is minor cosmetic fix to add the trailing '\n'. Please check and apply them. Thanks, Wensong ---1463811584-2066790978-1067868947=:5797 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="linux-2.4-ipvs-tidyup.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-2.4-ipvs-tidyup.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTE3OCAgLT4gMS4xMTc5IA0KIwlu ZXQvaXB2NC9pcHZzL2lwX3ZzX2N0bC5jCTEuMiAgICAgLT4gMS4zICAgIA0K Iw0KIyBUaGUgZm9sbG93aW5nIGlzIHRoZSBCaXRLZWVwZXIgQ2hhbmdlU2V0 IExvZw0KIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KIyAwMy8xMS8wMwl3ZW5zb25nQGxpbnV4LXZzLm9yZwkxLjEx NzkNCiMgW0lQVlNdIENvc21ldGljIElQX1ZTX0lORk8gZml4IHRvIGFkZCB0 aGUgdHJhaWxpbmcgJ1xuJw0KIyANCiMgUGF0Y2ggZnJvbSBIb3JtcyA8aG9y bXNAdmVyZ2VuZXQubmV0Pg0KIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KIw0KZGlmZiAtTnJ1IGEvbmV0L2lwdjQv aXB2cy9pcF92c19jdGwuYyBiL25ldC9pcHY0L2lwdnMvaXBfdnNfY3RsLmMN Ci0tLSBhL25ldC9pcHY0L2lwdnMvaXBfdnNfY3RsLmMJTW9uIE5vdiAgMyAy MTo1Nzo0NCAyMDAzDQorKysgYi9uZXQvaXB2NC9pcHZzL2lwX3ZzX2N0bC5j CU1vbiBOb3YgIDMgMjE6NTc6NDQgMjAwMw0KQEAgLTE3NDAsOSArMTc0MCw5 IEBADQogCSAqIENoZWNrIGZvciB2YWxpZCBwcm90b2NvbDogVENQIG9yIFVE UC4gRXZlbiBmb3IgZndtYXJrIT0wDQogCSAqLw0KIAlpZiAodXJ1bGUtPnBy b3RvY29sIT1JUFBST1RPX1RDUCAmJiB1cnVsZS0+cHJvdG9jb2whPUlQUFJP VE9fVURQKSB7DQotCQlJUF9WU19JTkZPKCJ2c19jdGw6IGludmFsaWQgcHJv dG9jb2w6ICVkICVkLiVkLiVkLiVkOiVkICVzIiwNCi0JCQkgICBudG9ocyh1 cnVsZS0+cHJvdG9jb2wpLCBOSVBRVUFEKHVydWxlLT52YWRkciksDQotCQkJ ICAgbnRvaHModXJ1bGUtPnZwb3J0KSwgdXJ1bGUtPnNjaGVkX25hbWUpOw0K KwkJSVBfVlNfRVJSKCJzZXRfY3RsOiBpbnZhbGlkIHByb3RvY29sICVkICVk LiVkLiVkLiVkOiVkICVzXG4iLA0KKwkJCSAgbnRvaHModXJ1bGUtPnByb3Rv Y29sKSwgTklQUVVBRCh1cnVsZS0+dmFkZHIpLA0KKwkJCSAgbnRvaHModXJ1 bGUtPnZwb3J0KSwgdXJ1bGUtPnNjaGVkX25hbWUpOw0KIAkJcmV0ID0gLUVG QVVMVDsNCiAJCWdvdG8gb3V0X3VubG9jazsNCiAJfQ0K ---1463811584-2066790978-1067868947=:5797 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="linux-2.5-ipvs-tidyup.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-2.5-ipvs-tidyup.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTQwMyAgLT4gMS4xNDA0IA0KIwlu ZXQvaXB2NC9pcHZzL2lwX3ZzX2N0bC5jCTEuMTEgICAgLT4gMS4xMiAgIA0K Iw0KIyBUaGUgZm9sbG93aW5nIGlzIHRoZSBCaXRLZWVwZXIgQ2hhbmdlU2V0 IExvZw0KIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KIyAwMy8xMS8wMwl3ZW5zb25nQGxpbnV4LXZzLm9yZwkxLjE0 MDQNCiMgW0lQVlNdIENvc21ldGljIElQX1ZTX0lORk8gZml4IHRvIGFkZCB0 aGUgdHJhaWxpbmcgJ1xuJw0KIyANCiMgUGF0Y2ggZnJvbSBIb3JtcyA8aG9y bXNAdmVyZ2VuZXQubmV0Pg0KIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KIw0KZGlmZiAtTnJ1IGEvbmV0L2lwdjQv aXB2cy9pcF92c19jdGwuYyBiL25ldC9pcHY0L2lwdnMvaXBfdnNfY3RsLmMN Ci0tLSBhL25ldC9pcHY0L2lwdnMvaXBfdnNfY3RsLmMJTW9uIE5vdiAgMyAy MjoxMDozMiAyMDAzDQorKysgYi9uZXQvaXB2NC9pcHZzL2lwX3ZzX2N0bC5j CU1vbiBOb3YgIDMgMjI6MTA6MzIgMjAwMw0KQEAgLTE4MzksOSArMTgzOSw5 IEBADQogDQogCS8qIENoZWNrIGZvciB2YWxpZCBwcm90b2NvbDogVENQIG9y IFVEUCwgZXZlbiBmb3IgZndtYXJrIT0wICovDQogCWlmICh1c3ZjLT5wcm90 b2NvbCE9SVBQUk9UT19UQ1AgJiYgdXN2Yy0+cHJvdG9jb2whPUlQUFJPVE9f VURQKSB7DQotCQlJUF9WU19JTkZPKCJ2c19jdGw6IGludmFsaWQgcHJvdG9j b2w6ICVkICVkLiVkLiVkLiVkOiVkICVzIiwNCi0JCQkgICBudG9ocyh1c3Zj LT5wcm90b2NvbCksIE5JUFFVQUQodXN2Yy0+YWRkciksDQotCQkJICAgbnRv aHModXN2Yy0+cG9ydCksIHVzdmMtPnNjaGVkX25hbWUpOw0KKwkJSVBfVlNf RVJSKCJzZXRfY3RsOiBpbnZhbGlkIHByb3RvY29sICVkICVkLiVkLiVkLiVk OiVkICVzXG4iLA0KKwkJCSAgbnRvaHModXN2Yy0+cHJvdG9jb2wpLCBOSVBR VUFEKHVzdmMtPmFkZHIpLA0KKwkJCSAgbnRvaHModXN2Yy0+cG9ydCksIHVz dmMtPnNjaGVkX25hbWUpOw0KIAkJcmV0ID0gLUVGQVVMVDsNCiAJCWdvdG8g b3V0X3VubG9jazsNCiAJfQ0K ---1463811584-2066790978-1067868947=:5797-- From hch@infradead.org Mon Nov 3 07:12:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Nov 2003 07:12:52 -0800 (PST) Received: from phoenix.infradead.org (pub234.cambridge.redhat.com [213.86.99.234] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3FC725003995 for ; Mon, 3 Nov 2003 07:12:12 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.22) id 1AGgMr-0007cx-Ck; Mon, 03 Nov 2003 15:11:45 +0000 Date: Mon, 3 Nov 2003 15:11:45 +0000 From: Christoph Hellwig To: "David S. Miller" Cc: Rusty Russell , anton@samba.org, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: net/core/flow.c cpu handling? Message-ID: <20031103151145.A29287@infradead.org> References: <20031102062345.A472E2C0CD@lists.samba.org> <20031101225050.4de96a8b.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031101225050.4de96a8b.davem@redhat.com>; from davem@redhat.com on Sat, Nov 01, 2003 at 10:50:50PM -0800 X-archive-position: 1189 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev On Sat, Nov 01, 2003 at 10:50:50PM -0800, David S. Miller wrote: > > Very likely, the code is how it is in order to make the > 2.4.x backport of this code and the 2.6.x version as > similar as humanly possible. Well, the current code is wrong for 2.6 and breaks badly for machines with more than 32/64 cpus. -- Christoph Hellwig - Freelance Hacker Contact me for driver hacking and kernel development consulting From yoshfuji@linux-ipv6.org Mon Nov 3 10:24:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Nov 2003 10:24:55 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3IOK25008919 for ; Mon, 3 Nov 2003 10:24:21 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-6.6) with ESMTP id hA3IO2lg028840; Tue, 4 Nov 2003 03:24:02 +0900 Date: Tue, 04 Nov 2003 03:24:02 +0900 (JST) Message-Id: <20031104.032402.67222659.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: dwmw2@infradead.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: IPv6 on-link assumption considered harmful From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <1067615762.3423.264.camel@hades.cambridge.redhat.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1190 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello. In article (at Mon, 3 Nov 2003 09:26:36 +0200 (EET)), Pekka Savola says: > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt > > This has nothing to do with this subject (AFAICS), but one person just a > couple of days ago asked about this and wanted to know whether anyone else > is hacking this, and if not, whether he should go ahead. We gave (as > radvd maintainers) a thumbs-up. Host code is already available in USAGI tree since January, 2003. I'll contribute this to mainline (after 2.6.0). Thanks. --yoshfuji From pp@ee.oulu.fi Mon Nov 3 12:53:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Nov 2003 12:54:20 -0800 (PST) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3Krg25015981 for ; Mon, 3 Nov 2003 12:53:43 -0800 Received: from tk28.oulu.fi (tk28 [130.231.48.68]) by ee.oulu.fi (8.12.10/8.12.10) with ESMTP id hA3KrawE026468; Mon, 3 Nov 2003 22:53:36 +0200 (EET) Received: (from pp@localhost) by tk28.oulu.fi (8.12.10/8.12.10/Submit) id hA3KrZfS012571; Mon, 3 Nov 2003 22:53:35 +0200 (EET) Date: Mon, 3 Nov 2003 22:53:35 +0200 From: Pekka Pietikainen To: Charles Bueche Cc: netdev@oss.sgi.com Subject: Re: changing MTU on b44 breaks eth0 Message-ID: <20031103205335.GA7668@ee.oulu.fi> References: <1067888106.3366.20.camel@bluez.bueche.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <1067888106.3366.20.camel@bluez.bueche.ch> User-Agent: Mutt/1.4.1i X-archive-position: 1191 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pp@ee.oulu.fi Precedence: bulk X-list: netdev On Mon, Nov 03, 2003 at 08:35:38PM +0100, Charles Bueche wrote: > Hi, > > I tried to reduce the MTU to 1464 because I'm behind an ADSL router. > Rigth when I do the "ifconfig eth0 192.168.0.4 mtu 1464", it hangs the > port. > The problem can be reproduced. I have attached a few log extracts. I > would be ready to test patches or new versions if needed. Heh Thanks for the report. Looking at the code and previous bugs in it, I can safely say I found the problem and a few similar ones that could be triggered when using ethtool :-) Anyway, here's a (untested) patch that should fix the problem. As a bonus I even snuck in a new feature, power management support! --- /usr/src/linux-2.6.0-0.test9.1.67/drivers/net/b44.c 2003-10-25 21:43:30.000000000 +0300 +++ linux-2.6.0-test9/drivers/net/b44.c 2003-11-03 22:25:15.943854312 +0200 @@ -25,8 +25,8 @@ #define DRV_MODULE_NAME "b44" #define PFX DRV_MODULE_NAME ": " -#define DRV_MODULE_VERSION "0.91" -#define DRV_MODULE_RELDATE "Oct 3, 2003" +#define DRV_MODULE_VERSION "0.92" +#define DRV_MODULE_RELDATE "Nov 3, 2003" #define B44_DEF_MSG_ENABLE \ (NETIF_MSG_DRV | \ @@ -942,6 +942,8 @@ b44_init_hw(bp); spin_unlock_irq(&bp->lock); + b44_enable_ints(bp); + return 0; } @@ -1558,6 +1560,8 @@ netif_wake_queue(bp->dev); spin_unlock_irq(&bp->lock); + b44_enable_ints(bp); + return 0; } case ETHTOOL_GPAUSEPARAM: { @@ -1601,6 +1605,8 @@ } spin_unlock_irq(&bp->lock); + b44_enable_ints(bp); + return 0; } }; @@ -1852,11 +1858,57 @@ } } +#ifdef CONFIG_PM +static int b44_suspend(struct pci_dev *pdev, u32 state) +{ + struct net_device *dev = pci_get_drvdata(pdev); + struct b44 *bp = dev->priv; + + if (!netif_running(dev)) + return 0; + + del_timer_sync(&bp->timer); + + spin_lock_irq(&bp->lock); + + b44_halt(bp); + netif_carrier_off(bp->dev); + netif_device_detach(bp->dev); + b44_free_rings(bp); + + spin_unlock_irq(&bp->lock); + return 0; +} + +static int b44_resume(struct pci_dev *pdev) +{ + struct net_device *dev = pci_get_drvdata(pdev); + struct b44 *bp = dev->priv; + + if (!netif_running(dev)) + return 0; + + spin_lock_irq(&bp->lock); + + b44_init_rings(bp); + b44_init_hw(bp); + netif_device_attach(bp->dev); + spin_unlock_irq(&bp->lock); + + b44_enable_ints(bp); + return 0; +} +#endif /* CONFIG_PM */ + static struct pci_driver b44_driver = { .name = DRV_MODULE_NAME, .id_table = b44_pci_tbl, .probe = b44_init_one, .remove = __devexit_p(b44_remove_one), +#ifdef CONFIG_PM + .suspend = b44_suspend, + .resume = b44_resume, +#endif /* CONFIG_PM */ }; static int __init b44_init(void) From davem@pizda.ninka.net Mon Nov 3 14:50:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Nov 2003 14:51:13 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3MoI25019437 for ; Mon, 3 Nov 2003 14:50:38 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id OAA16260; Mon, 3 Nov 2003 14:45:21 -0800 Date: Mon, 3 Nov 2003 14:45:21 -0800 From: "David S. Miller" To: Rusty Russell Cc: anton@samba.org, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: net/core/flow.c cpu handling? Message-Id: <20031103144521.0aec9ea3.davem@redhat.com> In-Reply-To: <20031103102829.E1C622C05E@lists.samba.org> References: <20031101225050.4de96a8b.davem@redhat.com> <20031103102829.E1C622C05E@lists.samba.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1192 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 03 Nov 2003 21:26:40 +1100 Rusty Russell wrote: > In message <20031101225050.4de96a8b.davem@redhat.com> you write: > > > > Very likely, the code is how it is in order to make the > > 2.4.x backport of this code and the 2.6.x version as > > similar as humanly possible. > > Hmm, AFAICT the patch I sent should be easier, not harder to backport. > > Anyway, I'm carrying the patch as part of the hotplug CPU patches: we > can discuss it once 2.6.0 is out. I intend to review your patch today, there is no justification for the problems you've pointed out in this code regardless of how difficult or easy fixing it makes a backport. From davem@pizda.ninka.net Mon Nov 3 14:52:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Nov 2003 14:52:43 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3MqB25019630 for ; Mon, 3 Nov 2003 14:52:11 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id OAA16267; Mon, 3 Nov 2003 14:47:07 -0800 Date: Mon, 3 Nov 2003 14:47:07 -0800 From: "David S. Miller" To: Wensong Zhang Cc: netdev@oss.sgi.com, ja@ssi.bg Subject: Re: [2.4/2.6 PATCH] Cosmetic IP_VS_INFO fix Message-Id: <20031103144707.30fa18df.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1193 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Cosmetic fixes can wait for 2.6.1 and 2.4.24 From davem@pizda.ninka.net Mon Nov 3 15:00:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Nov 2003 15:01:19 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3N0j25020236 for ; Mon, 3 Nov 2003 15:00:45 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id OAA16281; Mon, 3 Nov 2003 14:55:39 -0800 Date: Mon, 3 Nov 2003 14:55:39 -0800 From: "David S. Miller" To: Christoph Hellwig Cc: rusty@rustcorp.com.au, anton@samba.org, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: net/core/flow.c cpu handling? Message-Id: <20031103145539.17f3ba01.davem@redhat.com> In-Reply-To: <20031103151145.A29287@infradead.org> References: <20031102062345.A472E2C0CD@lists.samba.org> <20031101225050.4de96a8b.davem@redhat.com> <20031103151145.A29287@infradead.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1194 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 3 Nov 2003 15:11:45 +0000 Christoph Hellwig wrote: > On Sat, Nov 01, 2003 at 10:50:50PM -0800, David S. Miller wrote: > > > > Very likely, the code is how it is in order to make the > > 2.4.x backport of this code and the 2.6.x version as > > similar as humanly possible. > > Well, the current code is wrong for 2.6 and breaks badly for machines > with more than 32/64 cpus. I totally understand, I am in no way trying to justify what the code is doing. From davem@pizda.ninka.net Mon Nov 3 15:21:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Nov 2003 15:21:50 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3NLG25020760 for ; Mon, 3 Nov 2003 15:21:16 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id PAA16422; Mon, 3 Nov 2003 15:16:18 -0800 Date: Mon, 3 Nov 2003 15:16:18 -0800 From: "David S. Miller" To: Pekka Pietikainen Cc: charles@bueche.ch, netdev@oss.sgi.com Subject: Re: changing MTU on b44 breaks eth0 Message-Id: <20031103151618.79704b30.davem@redhat.com> In-Reply-To: <20031103205335.GA7668@ee.oulu.fi> References: <1067888106.3366.20.camel@bluez.bueche.ch> <20031103205335.GA7668@ee.oulu.fi> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1195 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 3 Nov 2003 22:53:35 +0200 Pekka Pietikainen wrote: > Anyway, here's a (untested) patch that should fix the problem. As a bonus I > even snuck in a new feature, power management support! I think Jeff should merge this upstrea, but I really disagree with the CONFIG_PM ifdefs for the power-management support. From pp@ee.oulu.fi Tue Nov 4 03:16:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 03:16:38 -0800 (PST) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4BFx25022355 for ; Tue, 4 Nov 2003 03:16:00 -0800 Received: from tk28.oulu.fi (tk28 [130.231.48.68]) by ee.oulu.fi (8.12.10/8.12.10) with ESMTP id hA4BFuwE023940; Tue, 4 Nov 2003 13:15:56 +0200 (EET) Received: (from pp@localhost) by tk28.oulu.fi (8.12.10/8.12.10/Submit) id hA4BFthM027680; Tue, 4 Nov 2003 13:15:55 +0200 (EET) Date: Tue, 4 Nov 2003 13:15:55 +0200 From: Pekka Pietikainen To: "David S. Miller" Cc: charles@bueche.ch, netdev@oss.sgi.com Subject: Re: changing MTU on b44 breaks eth0 Message-ID: <20031104111555.GA26860@ee.oulu.fi> References: <1067888106.3366.20.camel@bluez.bueche.ch> <20031103205335.GA7668@ee.oulu.fi> <20031103151618.79704b30.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20031103151618.79704b30.davem@redhat.com> User-Agent: Mutt/1.4.1i X-archive-position: 1196 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pp@ee.oulu.fi Precedence: bulk X-list: netdev On Mon, Nov 03, 2003 at 03:16:18PM -0800, David S. Miller wrote: > I think Jeff should merge this upstrea, but I really disagree > with the CONFIG_PM ifdefs for the power-management support. Fine with me (patch with CONFIG_PM removed included) Oh btw., when trying out whether the new code even compiles/loads I got the following in rmmod, does it look like something caused by generic code or should I look for a reason in b44? :-) (This is 2.6.0-test9-bk6). kernel BUG at net/core/dev.c:2882! invalid operand: 0000 [#1] CPU: 0 EIP: 0060:[] Tainted: P EFLAGS: 00010297 EIP is at free_netdev+0x2d/0x40 eax: ddfd6800 ebx: ddfd6800 ecx: 1f2e9da0 edx: 00000003 esi: dff5d000 edi: dff5d054 ebp: de743ec4 esp: de743ec4 ds: 007b es: 007b ss: 0068 Process rmmod (pid: 18966, threadinfo=de742000 task=c797b320) Stack: de743edc e090011d ddfd6800 dff5d000 e0902544 00000000 de743eec c01c8c09 dff5d000 dff5d054 de743f04 c0210dd0 dff5d054 dff5d080 e0902590 e0902590 de743f18 c0210e02 dff5d054 e0902544 c02fb458 de743f2c c0211039 e0902544 Call Trace: [] b44_remove_one+0x3d/0x60 [b44] [] pci_device_remove+0x39/0x40 [] device_release_driver+0x60/0x70 [] driver_detach+0x22/0x40 [] bus_remove_driver+0x39/0x70 [] driver_unregister+0x14/0x26 [] pci_unregister_driver+0x17/0x30 [] b44_cleanup+0x12/0x14 [b44] [] sys_delete_module+0x113/0x190 [] do_munmap+0x14f/0x1b0 [] sys_munmap+0x43/0x60 [] sysenter_past_esp+0x52/0x71 Code: 0f 0b 42 0b ab 48 2e c0 eb de c9 e9 93 6e ef ff 8d 76 00 55 Trying to reproduce on a fresh non-nvidia-tainted -bk8 rmmod initially worked, then I did /sbin/modprobe b44; /sbin/ifup eth0; /sbin/rmmod b44 managed to trigger another race: eth0: no IPv6 routers present Unable to handle kernel paging request at virtual address 706647ef printing eip: c0254415 *pde = 00000000 Oops: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010216 EIP is at rtnetlink_fill_ifinfo+0x2a5/0x480 eax: 706647e3 ebx: df037800 ecx: 00000ee4 edx: c68fa09c esi: 00000000 edi: df037805 ebp: dff8deb4 esp: dff8de88 ds: 007b es: 007b ss: 0068 Process events/0 (pid: 3, threadinfo=dff8c000 task=c151cc80) Stack: c689fd80 00000004 00000004 dff8dea4 00000ee4 00000f60 c68fa000 000005dc c689fd80 ffffffff 00000011 dff8dee4 c02548ac c689fd80 df037800 00000011 00000000 00000000 ffffffff df037800 c0335c00 df037800 00000006 dff8def8 Call Trace: [] rtmsg_ifinfo+0x5c/0xd0 [] rtnetlink_event+0x35/0x62 [] notifier_call_chain+0x2d/0x50 [] netdev_wait_allrefs+0xc0/0x110 [] netdev_run_todo+0x10c/0x1f0 [] __down_failed+0xb/0x14 [] worker_thread+0x1bb/0x2a0 [] linkwatch_event+0x0/0x30 [] default_wake_function+0x0/0x30 [] ret_from_fork+0x6/0x14 [] default_wake_function+0x0/0x30 [] worker_thread+0x0/0x2a0 [] kernel_thread_helper+0x5/0xc Code: 8b 50 0c b9 ff ff ff ff 31 c0 83 c2 08 89 d7 f2 ae f7 d1 49 --- /usr/src/linux-2.6.0-0.test9.1.67/drivers/net/b44.c 2003-10-25 21:43:30.000000000 +0300 +++ linux-2.6.0-test9/drivers/net/b44.c 2003-11-04 12:32:13.403426192 +0200 @@ -25,8 +25,8 @@ #define DRV_MODULE_NAME "b44" #define PFX DRV_MODULE_NAME ": " -#define DRV_MODULE_VERSION "0.91" -#define DRV_MODULE_RELDATE "Oct 3, 2003" +#define DRV_MODULE_VERSION "0.92" +#define DRV_MODULE_RELDATE "Nov 4, 2003" #define B44_DEF_MSG_ENABLE \ (NETIF_MSG_DRV | \ @@ -942,6 +942,8 @@ b44_init_hw(bp); spin_unlock_irq(&bp->lock); + b44_enable_ints(bp); + return 0; } @@ -1558,6 +1560,8 @@ netif_wake_queue(bp->dev); spin_unlock_irq(&bp->lock); + b44_enable_ints(bp); + return 0; } case ETHTOOL_GPAUSEPARAM: { @@ -1601,6 +1605,8 @@ } spin_unlock_irq(&bp->lock); + b44_enable_ints(bp); + return 0; } }; @@ -1852,11 +1858,53 @@ } } +static int b44_suspend(struct pci_dev *pdev, u32 state) +{ + struct net_device *dev = pci_get_drvdata(pdev); + struct b44 *bp = dev->priv; + + if (!netif_running(dev)) + return 0; + + del_timer_sync(&bp->timer); + + spin_lock_irq(&bp->lock); + + b44_halt(bp); + netif_carrier_off(bp->dev); + netif_device_detach(bp->dev); + b44_free_rings(bp); + + spin_unlock_irq(&bp->lock); + return 0; +} + +static int b44_resume(struct pci_dev *pdev) +{ + struct net_device *dev = pci_get_drvdata(pdev); + struct b44 *bp = dev->priv; + + if (!netif_running(dev)) + return 0; + + spin_lock_irq(&bp->lock); + + b44_init_rings(bp); + b44_init_hw(bp); + netif_device_attach(bp->dev); + spin_unlock_irq(&bp->lock); + + b44_enable_ints(bp); + return 0; +} + static struct pci_driver b44_driver = { .name = DRV_MODULE_NAME, .id_table = b44_pci_tbl, .probe = b44_init_one, .remove = __devexit_p(b44_remove_one), + .suspend = b44_suspend, + .resume = b44_resume, }; static int __init b44_init(void) -- Pekka Pietikainen From kuznet@ms2.inr.ac.ru Tue Nov 4 04:34:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 04:34:45 -0800 (PST) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [193.233.7.111]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4CYA25030301 for ; Tue, 4 Nov 2003 04:34:11 -0800 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id PAA15518; Tue, 4 Nov 2003 15:33:03 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200311041233.PAA15518@yakov.inr.ac.ru> Subject: Re: Fw: issues with SO_PRIORITY and IP_TOS To: davem@redhat.com (David S. Miller) Date: Tue, 4 Nov 2003 15:33:03 +0300 (MSK) Cc: jmorris@redhat.com, cfriesen@nortelnetworks.com, hadi@znyx.com, netdev@oss.sgi.com In-Reply-To: <20031030120140.678b721b.davem@redhat.com> from "David S. Miller" at ïËÔ 30, 2003 12:01:40 X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1197 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! [cced to Jamal] > I've always been confused about all of the weird things > we do to handle DSCP et al. when masking the TOS bits all > over the place. TOS bits are masked only in one place: when doing routing by TOS, implemented by some existing routing engines sort of OSPF. No bits but TOS bits are used for these things. > Alexey, what is going on here? #1. Setting priority derived from TOS is different thing, it is just to make life more convenient for old and still existing applications: telnet, ftp, ssh, which set TOS bits in some way, which used to be reasonable. Actually, even not four bits but only two bits are used. #2. If the host is inside diffserv environment all these things just have no effects and make no sense. That's why we do not change anything (except for disabling access to ECN bits). > reasons. Firstly, if we're using the old bit fields it should be the > precedence bits that are used for the skb priority rather than the tos > field. Secondly, the whole precedence/tos thing has been obsoleted by > the 6-bit DSCP field, of which the first 3 bits are supposed to be > backwards compatible with the old precedence field. Shouldn't we > properly handle that? See above #1. Precedence bits used to be _non-sense_ in the past and their use outside of context of setup of your routers (in pre-DS world) or outide context of diffserv does not make sense. What's about "backward-compatibility", it sounds funny, DS is made compatible with Cisco use precedence and this has nothing to do with end users (where socket options make sense), precedence bits are rewritten by routers for their own use. > Secondly, for vlan priority tagging there are only 3 bits available. > This means that practically speaking anyone using vlan priorities needs > to limit themselves to priorities 0-7. Thirdly. :-) Technically speaking, direct access of user to such things is prohibited in any case. So, use proper classifiers to do right mappings. > Currently, for me to send a packet with IP precedence bits set to a > nonzero value *and* vlan priority set to the same value, I have to do > the following: > > int opt = PRIORITY << 5; > setsockopt(mysocks[i], SOL_IP, IP_TOS, &opt, sizeof(opt)); > opt = PRIORITY; > setsockopt(mysocks[i], SOL_SOCKET, SO_PRIORITY, &opt, sizeof(opt)); This is right. > This is kind of ugly. Hmm.. This is kinda nice. IP_TOS sets real TOS bits without any funny shifts and masks, but with some reasonable access control, SO_PRIORITY sets priority. TOS and PRIORITY are not related. > I propose adding a new IP socket option, IP_DSCP, > which would let you set the 6-bit DSCP value (which is then shifted by > two bits in the kernel to generate the 8-bit value for the header > field). I do not even think that IP_DSCP makes sense in diffserv environment. Packets are marked according to DS rules, not according to desire of particular user. Anyway, the thing which you suggest is equal to IP_TOS in this part. > The high-order 3 bits would then be automatically used to set > the socket priority to make a vlan egress mapping simple. Not even subject to discuss... In old current world it is just wrong, in new world it is even wronger. If DSCP is used for prioritizing, it is used via proper classifiers, not via some rules hardcoded to kernel. Alexey From an3h0ny@yahoo.fr Tue Nov 4 05:32:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 05:33:15 -0800 (PST) Received: from web11105.mail.yahoo.com (web11105.mail.yahoo.com [216.136.131.152]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4DWf25032470 for ; Tue, 4 Nov 2003 05:32:41 -0800 Message-ID: <20031104133240.89887.qmail@web11105.mail.yahoo.com> Received: from [195.68.44.148] by web11105.mail.yahoo.com via HTTP; Tue, 04 Nov 2003 14:32:40 CET Date: Tue, 4 Nov 2003 14:32:40 +0100 (CET) From: =?iso-8859-1?q?an7?= Subject: tcp checksumming To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 1198 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: an3h0ny@yahoo.fr Precedence: bulk X-list: netdev Hello, In tcp_rcv_established(), when you are in fast path, you use checksum and copy (the first function in the chain is tcp_copy_to_iovec) to finally delivering data to the user. I browse datagram.c,checksum.h,skbuff.c,tcp_input.c and only sees (mainly by following function calls in datagram.c) checksum calculation, by a lot of calls to csum_fold() and csum_partial(), and copy to iovec, but i have never seen the checksum _verification_. I learn that skb->csum is (when you have not CHECKSUM UNECESSARY defined in the case of a device computing the checksum by itself) the checksum on running data.But it is used in all functions,and get replaced by a function result. I don't see where it is used as a comparison My question is pretty simple : where in the code, is the tcp checksum verified (compared to the computed one). My first impression was that it was done in the *copy_and_csum* functions, but i only see checksum computation. That is to say, it is like a side effect of keeping data in a buffer with a bad checksum.(maybe it is removed after ? i don't think so) PS : i have posted here many times, never get an answer. Please pay a little attention ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com From an3h0ny@yahoo.fr Tue Nov 4 05:36:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 05:37:02 -0800 (PST) Received: from web11102.mail.yahoo.com (web11102.mail.yahoo.com [216.136.131.149]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4DaG25000408 for ; Tue, 4 Nov 2003 05:36:28 -0800 Message-ID: <20031104133615.86082.qmail@web11102.mail.yahoo.com> Received: from [195.68.44.148] by web11102.mail.yahoo.com via HTTP; Tue, 04 Nov 2003 14:36:15 CET Date: Tue, 4 Nov 2003 14:36:15 +0100 (CET) From: =?iso-8859-1?q?an7?= Subject: tcp checksumming To: davem@redhat.com Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 1199 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: an3h0ny@yahoo.fr Precedence: bulk X-list: netdev Hello, In tcp_rcv_established(), when you are in fast path, you use checksum and copy (the first function in the chain is tcp_copy_to_iovec) to finally delivering data to the user. I browse datagram.c,checksum.h,skbuff.c,tcp_input.c and only sees (mainly by following function calls in datagram.c) checksum calculation, by a lot of calls to csum_fold() and csum_partial(), and copy to iovec, but i have never seen the checksum _verification_. I learn that skb->csum is (when you have not CHECKSUM UNECESSARY defined in the case of a device computing the checksum by itself) the checksum on running data.But it is used in all functions,and get replaced by a function result. I don't see where it is used as a comparison My question is pretty simple : where in the code, is the tcp checksum verified (compared to the computed one). My first impression was that it was done in the *copy_and_csum* functions, but i only see checksum computation. That is to say, it is like a side effect of keeping data in a buffer with a bad checksum.(maybe it is removed after ? i don't think so) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com From rmk@arm.linux.org.uk Tue Nov 4 06:28:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 06:29:28 -0800 (PST) Received: from caramon.arm.linux.org.uk (caramon.arm.linux.org.uk [212.18.232.186]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4ESm25001317 for ; Tue, 4 Nov 2003 06:28:49 -0800 Received: from flint.arm.linux.org.uk ([2002:d412:e8ba:1:201:2ff:fe14:8fad]) by caramon.arm.linux.org.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.22) id 1AH2Ai-0003ca-1L; Tue, 04 Nov 2003 14:28:40 +0000 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.22) id 1AH2Ah-0003GZ-9R; Tue, 04 Nov 2003 14:28:39 +0000 Date: Tue, 4 Nov 2003 14:28:39 +0000 From: Russell King To: davem@redhat.com, netdev@oss.sgi.com Subject: Fwd: tcp checksumming Message-ID: <20031104142839.C2207@flint.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i X-Message-Flag: Your copy of Microsoft Outlook is vulnerable to viruses. See www.mutt.org for more details. X-archive-position: 1200 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rmk@arm.linux.org.uk Precedence: bulk X-list: netdev Not my problem. Please ensure that replies are directed at the appropriate address (ie not me.) Thanks. ----- Forwarded message from an7 ----- Date: Tue, 4 Nov 2003 15:17:59 +0100 (CET) From: an7 Subject: tcp checksumming Hello, i am sorry russel, but i asked many times on netdev without having the answer, i tried to understand by myself during two weeks..please help me In tcp_rcv_established(), when you are in fast path, you use checksum and copy (the first function in the chain is tcp_copy_to_iovec) to finally delivering data to the user. I browse datagram.c,checksum.h,skbuff.c,tcp_input.c and only sees (mainly by following function calls in datagram.c) checksum calculation, by a lot of calls to csum_fold() and csum_partial(), and copy to iovec, but i have never seen the checksum _verification_. I learn that skb->csum is (when you have not CHECKSUM UNECESSARY defined in the case of a device computing the checksum by itself) the checksum on running data.But it is used in all functions,and get replaced by a function result. I don't see where it is used as a comparison My question is pretty simple : where in the code, is the tcp checksum verified (compared to the computed one). My first impression was that it was done in the *copy_and_csum* functions, but i only see checksum computation. That is to say, it is like a side effect of keeping data in a buffer with a bad checksum.(maybe it is removed after ? i don't think so) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com ----- End forwarded message ----- -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core From hadi@znyx.com Tue Nov 4 08:04:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 08:05:18 -0800 (PST) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4G4b25003151 for ; Tue, 4 Nov 2003 08:04:37 -0800 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003110408031756:2421 ; Tue, 4 Nov 2003 08:03:17 -0800 Subject: Re: Fw: issues with SO_PRIORITY and IP_TOS From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Alexey Cc: "David S. Miller" , jmorris@redhat.com, cfriesen@nortelnetworks.com, netdev@oss.sgi.com In-Reply-To: <200311041233.PAA15518@yakov.inr.ac.ru> References: <200311041233.PAA15518@yakov.inr.ac.ru> Organization: Znyx Networks Message-Id: <1067961866.1031.41.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Nov 2003 11:04:26 -0500 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/04/2003 08:03:18 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/04/2003 08:03:27 AM, Serialize complete at 11/04/2003 08:03:27 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 1201 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev Hi, I agree with Alexey in regards to DSCP should be done by classifiers. Current mode of operation is: Whatever DSCP value you set will be reset by the network/box manager depending on some criteria they set. Applications running as root or sudo can of course open a netlink connection and set these values via a classifier. Actually one important thing easy to miss is that the IEEE priorities are reverse to what the IETF priorities are (who would have thunk, eh?). I havent looked at the VLAN code however blindly using the sk/skb->priority is _bad_ given that sk/skb->priority is based on IETF semantics. I bet you the Linux vlan code doesnt know this. cheers, jamal From cfriesen@nortelnetworks.com Tue Nov 4 09:03:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 09:04:14 -0800 (PST) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4H3e25009899 for ; Tue, 4 Nov 2003 09:03:40 -0800 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA4H2ko16582; Tue, 4 Nov 2003 12:02:47 -0500 (EST) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VRTPFR89; Tue, 4 Nov 2003 12:02:47 -0500 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V8PGYW84; Tue, 4 Nov 2003 12:02:47 -0500 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 049272E151; Tue, 4 Nov 2003 12:02:46 -0500 (EST) Message-ID: <3FA7DBB5.1090500@nortelnetworks.com> Date: Tue, 04 Nov 2003 12:02:45 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: kuznet@ms2.inr.ac.ru Cc: "David S. Miller" , jmorris@redhat.com, hadi@znyx.com, netdev@oss.sgi.com Subject: Re: Fw: issues with SO_PRIORITY and IP_TOS References: <200311041233.PAA15518@yakov.inr.ac.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1202 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev kuznet@ms2.inr.ac.ru wrote: >>Currently, for me to send a packet with IP precedence bits set to a >>nonzero value *and* vlan priority set to the same value, I have to do >>the following: >> >>int opt = PRIORITY << 5; >>setsockopt(mysocks[i], SOL_IP, IP_TOS, &opt, sizeof(opt)); >>opt = PRIORITY; >>setsockopt(mysocks[i], SOL_SOCKET, SO_PRIORITY, &opt, sizeof(opt)); > Hmm.. This is kinda nice. IP_TOS sets real TOS bits without any funny > shifts and masks, but with some reasonable access control, SO_PRIORITY > sets priority. TOS and PRIORITY are not related. If that were the case, I'd be happy. However, when you set the TOS bits (which really sets the whole 8-bit field, rather than just the 4 TOS bits), the kernel also sets the socket priority but only uses the TOS bits to do so. If we're going to set the whole 8-bit field, wouldn't it make sense to use the priority bits to set the priority? Or even leave the socket priority totally alone? This is why I proposed the IP_DSCP option which would have sane handling of the socket priority when setting the DSCP value. > I do not even think that IP_DSCP makes sense in diffserv environment. > Packets are marked according to DS rules, not according to desire > of particular user. If root wants to send out a packet with particular DSCP settings, doesn't it make sense to make that option available? It's a field in the IP packet header, we should be able to set it with an IP option. Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From davem@pizda.ninka.net Tue Nov 4 09:18:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 09:19:28 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4HIq25010376 for ; Tue, 4 Nov 2003 09:18:54 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id JAA18861; Tue, 4 Nov 2003 09:13:55 -0800 Date: Tue, 4 Nov 2003 09:13:55 -0800 From: "David S. Miller" To: Pekka Pietikainen Cc: charles@bueche.ch, netdev@oss.sgi.com Subject: Re: changing MTU on b44 breaks eth0 Message-Id: <20031104091355.70d6a3d1.davem@redhat.com> In-Reply-To: <20031104111555.GA26860@ee.oulu.fi> References: <1067888106.3366.20.camel@bluez.bueche.ch> <20031103205335.GA7668@ee.oulu.fi> <20031103151618.79704b30.davem@redhat.com> <20031104111555.GA26860@ee.oulu.fi> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1203 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 4 Nov 2003 13:15:55 +0200 Pekka Pietikainen wrote: > Oh btw., when trying out whether the new code even compiles/loads > I got the following in rmmod, does it look like something caused > by generic code or should I look for a reason in b44? :-) > (This is 2.6.0-test9-bk6). free_netdev() is being invoked before the device registration state advanced to NETREG_UNREGISTERED, likely unregister_netdev() has not been called first or a bogus pointer was passed into the routine. From davem@pizda.ninka.net Tue Nov 4 09:29:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 09:30:27 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4HTn25010813 for ; Tue, 4 Nov 2003 09:29:50 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id JAA18912; Tue, 4 Nov 2003 09:24:43 -0800 Date: Tue, 4 Nov 2003 09:24:43 -0800 From: "David S. Miller" To: Russell King Cc: netdev@oss.sgi.com, an3h0ny@yahoo.fr Subject: Re: Fwd: tcp checksumming Message-Id: <20031104092443.0dad265a.davem@redhat.com> In-Reply-To: <20031104142839.C2207@flint.arm.linux.org.uk> References: <20031104142839.C2207@flint.arm.linux.org.uk> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1204 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev > Not my problem. Sorry Russell, this an7 guy is getting really fucking annoying... He tried to force me to read the source code for him the other week too... so I definitely feel for you. From pp@ee.oulu.fi Tue Nov 4 13:19:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 13:20:19 -0800 (PST) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4LJc25016017 for ; Tue, 4 Nov 2003 13:19:39 -0800 Received: from tk28.oulu.fi (tk28 [130.231.48.68]) by ee.oulu.fi (8.12.10/8.12.10) with ESMTP id hA4LJbwE020171 for ; Tue, 4 Nov 2003 23:19:37 +0200 (EET) Received: (from pp@localhost) by tk28.oulu.fi (8.12.10/8.12.10/Submit) id hA4LJbXx004481 for netdev@oss.sgi.com; Tue, 4 Nov 2003 23:19:37 +0200 (EET) Date: Tue, 4 Nov 2003 23:19:37 +0200 From: Pekka Pietikainen To: netdev@oss.sgi.com Subject: Re: changing MTU on b44 breaks eth0 Message-ID: <20031104211937.GA3888@ee.oulu.fi> References: <1067888106.3366.20.camel@bluez.bueche.ch> <20031103205335.GA7668@ee.oulu.fi> <20031103151618.79704b30.davem@redhat.com> <20031104111555.GA26860@ee.oulu.fi> <20031104091355.70d6a3d1.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20031104091355.70d6a3d1.davem@redhat.com> User-Agent: Mutt/1.4.1i X-archive-position: 1205 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pp@ee.oulu.fi Precedence: bulk X-list: netdev On Tue, Nov 04, 2003 at 09:13:55AM -0800, David S. Miller wrote: > free_netdev() is being invoked before the device registration > state advanced to NETREG_UNREGISTERED, likely unregister_netdev() > has not been called first or a bogus pointer was passed into > the routine. Ah, like a missing SET_NETDEV_DEV? :-) I still got reliable rtnetlink_fill_ifinfo oopses (quick debugging showed strlen(dev->qdisc_sleeping->ops->id); to be the location of the oops), which went away after adding debug printk's to the module remove stuff, and didn't come back after removing them and instead removing the device from modprobe.conf (since I suspected it might have to do with the device getting rmmoded and getting immediately insmod'd since something tried to use the device). Then I put it back there and it's behaved since. Weird, or maybe I forgot a make modules_install before the initial fix. Whatever. Also added a add_timer() to resume, which it obviously needs... --- /usr/src/linux-2.6.0-0.test9.1.67/drivers/net/b44.c 2003-10-25 21:43:30.000000000 +0300 +++ linux-2.6.0-test9/drivers/net/b44.c 2003-11-04 22:12:25.776969400 +0200 @@ -25,8 +25,8 @@ #define DRV_MODULE_NAME "b44" #define PFX DRV_MODULE_NAME ": " -#define DRV_MODULE_VERSION "0.91" -#define DRV_MODULE_RELDATE "Oct 3, 2003" +#define DRV_MODULE_VERSION "0.92" +#define DRV_MODULE_RELDATE "Nov 4, 2003" #define B44_DEF_MSG_ENABLE \ (NETIF_MSG_DRV | \ @@ -942,6 +942,8 @@ b44_init_hw(bp); spin_unlock_irq(&bp->lock); + b44_enable_ints(bp); + return 0; } @@ -1558,6 +1560,8 @@ netif_wake_queue(bp->dev); spin_unlock_irq(&bp->lock); + b44_enable_ints(bp); + return 0; } case ETHTOOL_GPAUSEPARAM: { @@ -1601,6 +1605,8 @@ } spin_unlock_irq(&bp->lock); + b44_enable_ints(bp); + return 0; } }; @@ -1752,6 +1758,7 @@ } SET_MODULE_OWNER(dev); + SET_NETDEV_DEV(dev,&pdev->dev); /* No interesting netdevice features in this card... */ dev->features |= 0; @@ -1852,11 +1859,56 @@ } } +static int b44_suspend(struct pci_dev *pdev, u32 state) +{ + struct net_device *dev = pci_get_drvdata(pdev); + struct b44 *bp = dev->priv; + + if (!netif_running(dev)) + return 0; + + del_timer_sync(&bp->timer); + + spin_lock_irq(&bp->lock); + + b44_halt(bp); + netif_carrier_off(bp->dev); + netif_device_detach(bp->dev); + b44_free_rings(bp); + + spin_unlock_irq(&bp->lock); + return 0; +} + +static int b44_resume(struct pci_dev *pdev) +{ + struct net_device *dev = pci_get_drvdata(pdev); + struct b44 *bp = dev->priv; + + if (!netif_running(dev)) + return 0; + + spin_lock_irq(&bp->lock); + + b44_init_rings(bp); + b44_init_hw(bp); + netif_device_attach(bp->dev); + spin_unlock_irq(&bp->lock); + + bp->timer.expires = jiffies + HZ; + add_timer(&bp->timer); + + b44_enable_ints(bp); + return 0; +} + static struct pci_driver b44_driver = { .name = DRV_MODULE_NAME, .id_table = b44_pci_tbl, .probe = b44_init_one, .remove = __devexit_p(b44_remove_one), + .suspend = b44_suspend, + .resume = b44_resume, }; static int __init b44_init(void) -- Pekka Pietikainen From davem@pizda.ninka.net Tue Nov 4 13:25:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 13:26:08 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4LPF25016455 for ; Tue, 4 Nov 2003 13:25:35 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id NAA19893; Tue, 4 Nov 2003 13:20:17 -0800 Date: Tue, 4 Nov 2003 13:20:17 -0800 From: "David S. Miller" To: Pekka Pietikainen Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: changing MTU on b44 breaks eth0 Message-Id: <20031104132017.1d43a69c.davem@redhat.com> In-Reply-To: <20031104211937.GA3888@ee.oulu.fi> References: <1067888106.3366.20.camel@bluez.bueche.ch> <20031103205335.GA7668@ee.oulu.fi> <20031103151618.79704b30.davem@redhat.com> <20031104111555.GA26860@ee.oulu.fi> <20031104091355.70d6a3d1.davem@redhat.com> <20031104211937.GA3888@ee.oulu.fi> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1206 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 4 Nov 2003 23:19:37 +0200 Pekka Pietikainen wrote: > On Tue, Nov 04, 2003 at 09:13:55AM -0800, David S. Miller wrote: > > free_netdev() is being invoked before the device registration > > state advanced to NETREG_UNREGISTERED, likely unregister_netdev() > > has not been called first or a bogus pointer was passed into > > the routine. > Ah, like a missing SET_NETDEV_DEV? :-) Wonderful, Jeff please integrate this b44 patch from Pekka. From acme@conectiva.com.br Tue Nov 4 14:31:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 14:32:03 -0800 (PST) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4MVQ25017332 for ; Tue, 4 Nov 2003 14:31:29 -0800 Received: from [200.181.169.115] (helo=oops.kerneljanitors.org) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1AH9jQ-0001hd-00 for netdev@oss.sgi.com; Tue, 04 Nov 2003 20:33:01 -0200 Received: by oops.kerneljanitors.org (Postfix, from userid 500) id 81F3BE72F; Tue, 4 Nov 2003 22:31:19 +0000 (UTC) Date: Tue, 4 Nov 2003 20:31:19 -0200 From: Arnaldo Carvalho de Melo To: netdev@oss.sgi.com Subject: [Bug 1490] New: _decode_session[46] does not set type or code for ICMP or ICMPv6] Message-ID: <20031104223118.GB23401@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.4i X-archive-position: 1207 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev FYI ----- Forwarded message from bugme-daemon@osdl.org ----- Date: Tue, 4 Nov 2003 08:54:36 -0800 From: bugme-daemon@osdl.org Subject: [Bug 1490] New: _decode_session[46] does not set type or code for ICMP or ICMPv6 To: acme@conectiva.com.br http://bugme.osdl.org/show_bug.cgi?id=1490 Summary: _decode_session[46] does not set type or code for ICMP or ICMPv6 Kernel Version: 2.6.0-test9 Status: NEW Severity: normal Owner: acme@conectiva.com.br Submitter: bbuesker@qualcomm.com Distribution: Redhat 9 Hardware Environment: x86 Software Environment: ipsec-tools-0.2.2 Problem Description: The _decode_session[46] functions do not set the type and code for ICMP and ICMPv6. These values need to be set so that policies can be matched based on these fields, since setkey allows for specifying policies based on the type and code. Furthermore, __xfrm[46]_selector_match do not correctly handle ICMP and ICMPv6. The type should be compared against the xfrm_selector's sport field, and the code should be compared against the dport field. The type and code are both 8 bit fields, whereas __xfrm[46]_selector_match is comparing 16 bit values. Steps to reproduce: Insert a policy into the SPD using setkey that requires IPsec protection. For example, require inbound router advertisements to be protected with ESP with the following: spdadd ::/0 ::/0 icmp6 134,0 -P in ipsec esp/transport//require; Then send a router advertisement to the system under test. The packet will not be dropped, and the system will generate an IPv6 address. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. ----- End forwarded message ----- From davem@pizda.ninka.net Tue Nov 4 14:34:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 14:35:26 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4MYo25017670 for ; Tue, 4 Nov 2003 14:34:52 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id OAA20176; Tue, 4 Nov 2003 14:29:49 -0800 Date: Tue, 4 Nov 2003 14:29:49 -0800 From: "David S. Miller" To: Arnaldo Carvalho de Melo Cc: netdev@oss.sgi.com Subject: Re: [Bug 1490] New: _decode_session[46] does not set type or code for ICMP or ICMPv6] Message-Id: <20031104142949.0a57d416.davem@redhat.com> In-Reply-To: <20031104223118.GB23401@conectiva.com.br> References: <20031104223118.GB23401@conectiva.com.br> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1208 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 4 Nov 2003 20:31:19 -0200 Arnaldo Carvalho de Melo wrote: > FYI This should be posted to netdev so that people like Herbert Xu, Alexey, James Morris, and others can look at it. From acme@conectiva.com.br Tue Nov 4 14:35:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 14:35:36 -0800 (PST) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4MZ225017679 for ; Tue, 4 Nov 2003 14:35:03 -0800 Received: from [200.181.169.115] (helo=oops.kerneljanitors.org) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1AH9mv-0001vL-00 for netdev@oss.sgi.com; Tue, 04 Nov 2003 20:36:38 -0200 Received: by oops.kerneljanitors.org (Postfix, from userid 500) id D1BEFE72F; Tue, 4 Nov 2003 22:34:54 +0000 (UTC) Date: Tue, 4 Nov 2003 20:34:54 -0200 From: Arnaldo Carvalho de Melo To: netdev@oss.sgi.com Subject: [Bug 1491] New: No SADB_EXPIRE message sent when soft byte lifetime is reached] Message-ID: <20031104223453.GC23401@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.4i X-archive-position: 1209 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev One more... ----- Forwarded message from bugme-daemon@osdl.org ----- Date: Tue, 4 Nov 2003 09:26:37 -0800 From: bugme-daemon@osdl.org Subject: [Bug 1491] New: No SADB_EXPIRE message sent when soft byte lifetime is reached To: acme@conectiva.com.br http://bugme.osdl.org/show_bug.cgi?id=1491 Summary: No SADB_EXPIRE message sent when soft byte lifetime is reached Kernel Version: 2.6.0-test4 Status: NEW Severity: normal Owner: acme@conectiva.com.br Submitter: bbuesker@qualcomm.com Distribution: Redhat 9 Hardware Environment: x86 Software Environment: ipsec-tools-0.2.2 Problem Description: If byte lifetimes are used for IPsec security associations, the kernel does not send an SADB_EXPIRE message to the key management daemon (racoon) when the soft lifetime in terms of bytes is exceeded. Racoon only receives an SADB_EXPIRE message when the hard lifetime is exceeded. Steps to reproduce: Reenable byte lifetimes in racoon. Set up a security policy requiring IPsec, and with racoon running on two different machines, trigger the IKE negotiation by sending a packet. Once the SA is established, continue sending packets until the soft byte lifetime is exceeded. At this point, racoon should receive an SADB_EXPIRE message indicating the soft lifetime has been exceeded. This message is never sent by the kernel. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. ----- End forwarded message ----- From torvalds@osdl.org Tue Nov 4 14:44:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 14:44:56 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4MiM25018403 for ; Tue, 4 Nov 2003 14:44:22 -0800 Received: from localhost (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id hA4MiEC24127 for ; Tue, 4 Nov 2003 14:44:14 -0800 X-Received: from localhost (localhost.localdomain [127.0.0.1]) by home.osdl.org (8.12.10/8.12.10) with ESMTP id hA4MFdNW001952 for ; Tue, 4 Nov 2003 14:15:40 -0800 X-Received: from localhost.localdomain [127.0.0.1] by localhost with IMAP (fetchmail-6.2.0) for torvalds@localhost (single-drop); Tue, 04 Nov 2003 14:15:40 -0800 (PST) X-Received: from fire-1.osdl.org (air1.pdx.osdl.net [172.20.0.5]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id hA4MErC18450 for ; Tue, 4 Nov 2003 14:14:53 -0800 X-Received: from vger.kernel.org (vger.kernel.org [67.72.78.212]) by fire-1.osdl.org (8.12.8/8.12.8) with ESMTP id hA4MELAi024092 for ; Tue, 4 Nov 2003 14:14:52 -0800 X-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261267AbTKDWM4 (ORCPT ); Tue, 4 Nov 2003 17:12:56 -0500 X-Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261332AbTKDWM4 (ORCPT ); Tue, 4 Nov 2003 17:12:56 -0500 X-Received: from user-12hcje4.cable.mindspring.com ([69.22.77.196]:35464 "EHLO bender.davehollis.com") by vger.kernel.org with ESMTP id S261267AbTKDWMs (ORCPT ); Tue, 4 Nov 2003 17:12:48 -0500 X-Received: from davehollis.com (washdc3-ar10-4-63-121-042.washdc3.dsl-verizon.net [4.63.121.42]) (authenticated bits=0) by bender.davehollis.com (8.12.8/8.12.8) with ESMTP id hA4MCiOV024001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Nov 2003 17:12:45 -0500 Message-ID: <3FA8245B.8030302@davehollis.com> Date: Tue, 04 Nov 2003 17:12:43 -0500 From: David T Hollis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031027 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kernel Mailing List Subject: Oops in __xfrm4_state_lookup when setting up an IPSEC tunnel X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.36 X-Scanned-By: MIMEDefang 2.37 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org ReSent-Date: Tue, 4 Nov 2003 14:44:07 -0800 (PST) ReSent-From: Linus Torvalds ReSent-To: netdev@oss.sgi.com ReSent-Subject: Oops in __xfrm4_state_lookup when setting up an IPSEC tunnel ReSent-Message-ID: X-archive-position: 1210 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: torvalds@osdl.org Precedence: bulk X-list: netdev I am trying to setup an IPV4 IPSEC tunnel between two systems with the following topology: 192.168.1.0/24 | gw1 (2.6.0-test9-bk7) | 66.22.66.22 | Internet | 44.33.44.33 | gw2 (2.6.0-test9-bk9) | 172.16.100.100/24 Both firewalls are RedHat 9 based installs, running stock 2.6.0-test9 kernels (note the variance on bk7 and bk9). Both are running Shorewall 1.4.7c to setup iptables/netfilter firewalling. If I configure the SAD and SPDs on gw2, than setup them up on gw1, gw2 Oops hard on __xfrm4_state_lookup. I have not yet hand copied the entire dump but have the initial pertinent info: EIP is at __xfrm4_state_lookup+0x6f/0xa0 Call Stack is: xfrm_state_lookup xfrm_rcv_encap match [ ipt_conntrack ] match [ ipt_state ] ipt_do_table [ ip_tables ] ip_local_deliver ipt_hook [ iptable_filter] xfrm4_rcv ip_local_deliver_finish ip_local_deliver_finish nf_hook_slow ip_load_deliver_finish ip_local_deliver ip_local_deliver_finish ip_rcv_finish ip_rcv_finish nf_hook_slow Between reproductions of the crash (which are easy to repeat - that's good.... I guess..) the constant is that it's dying in the xfrm_state_lookup area. gw1 (the bk7 system) has not crashed in any way. tcpdump output on gw2 watching traffic to/from gw1 right at a crash: 17:02:42.147923 66.22.66.22 > 44.33.44.33: ESP(spi=0x00000201,seq=0x1) (DF) 17:02:42.147923 truncated-ip - 16 bytes missing! 66.22.66.22 > 69.0.0.84: truncated-ip - 16268 bytes missing! 44.33.44.33 > 69.0.0.84: xns-idp (frag 13060:16352@30720) (ipip-proto-4) 17:02:43.147660 66.22.66.22 > 44.33.44.33: ESP(spi=0x00000201,seq=0x2) (DF) 17:02:43.147660 truncated-ip - 16 bytes missing! 66.22.66.22 > 69.0.0.84: bad-hlen 0 (ipip-proto-4) 17:02:44.146738 66.22.66.22 > 44.33.44.33: ESP(spi=0x00000201,seq=0x3) (DF) 17:02:44.146738 truncated-ip - 16 bytes missing! 66.22.66.22 > 69.0.0.84: bad-hlen 8 (ipip-proto-4) /sbin/lsmod: Module Size Used by xfrm_user 15300 - md5 3936 - aes 32544 - des 11616 - ah4 7776 - esp4 10496 - af_key 32848 - autofs 15456 - serial_cs 8136 - 8250 20960 - serial_core 22240 - 3c574_cs 13804 - parport_pc 27240 - parport 43016 - ipt_ULOG 6440 - ipt_ttl 1824 - ipt_TOS 2432 - ipt_tos 1504 - ipt_TCPMSS 4224 - ipt_tcpmss 2176 - ipt_state 1824 - ipt_REJECT 6816 - ipt_REDIRECT 2080 - ipt_recent 10668 - ipt_pkttype 1504 - ipt_physdev 2064 - ipt_owner 3104 - ipt_multiport 1920 - ipt_MASQUERADE 3584 - ipt_MARK 1984 - ipt_mark 1568 - ipt_mac 1856 - ipt_LOG 5472 - ipt_limit 2272 - ipt_length 1600 - ipt_helper 2048 - ipt_esp 1856 - ipt_ECN 3200 - ipt_ecn 2112 - ipt_DSCP 2464 - ipt_dscp 1568 - ipt_conntrack 2432 - ipt_ah 1856 - ip_queue 10584 - ip_nat_tftp 3344 - ip_nat_snmp_basic 11588 - ip_nat_irc 4112 - ip_nat_ftp 4752 - ip_nat_amanda 2940 - ip_conntrack_tftp 3508 - ip_conntrack_irc 71220 - ip_conntrack_ftp 72084 - ip_conntrack_amanda 69796 - arpt_mangle 2336 - arptable_filter 1984 - arp_tables 12512 - iptable_nat 21964 - ip_conntrack 31536 - iptable_mangle 2720 - iptable_filter 2688 - ip_tables 16128 - hid 24992 - uhci_hcd 31184 - usbcore 107772 - My manual tunnel config: #!/sbin/setkey -f # Flush the SAD and SPD flush; spdflush; # ESP SAs doing encryption using 192 bit long keys (168 + 24 parity) # and authentication using 128 bit long keys add 66.22.66.22 44.33.44.33 esp 0x201 -m tunnel -E 3des-cbc 0x12d49767b12e4565d5fb95bf1d5248db93c60a90d7602a44 -A hmac-md5 0x2013c28f56dea12fae2835b3654d60a2; add 44.33.44.33 66.22.66.22 esp 0x301 -m tunnel -E 3des-cbc 0x40127f0a79fda7311b3c5344f5d5bd9a0fcd8bd926caae5f -A hmac-md5 0xd1b9a27cb7ab9562a0c8ad21f82be8b8; # Security policies spdadd 192.168.1.0/24 172.16.100.0/24 any -P out ipsec esp/tunnel/66.22.66.22-44.33.44.33/require; spdadd 172.16.100.0/24 192.168.1.0/24 any -P in ipsec esp/tunnel/44.33.44.33-66.22.66.22/require; /sbin/setkey -D: 44.33.44.33 66.22.66.22 esp mode=tunnel spi=769(0x00000301) reqid=0(0x00000000) E: 3des-cbc 40127f0a 79fda731 1b3c5344 f5d5bd9a 0fcd8bd9 26caae5f A: hmac-md5 d1b9a27c b7ab9562 a0c8ad21 f82be8b8 seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Nov 4 16:43:39 2003 current: Nov 4 16:44:35 2003 diff: 56(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=1 pid=3930 refcnt=0 66.22.66.22 44.33.44.33 esp mode=tunnel spi=513(0x00000201) reqid=0(0x00000000) E: 3des-cbc 12d49767 b12e4565 d5fb95bf 1d5248db 93c60a90 d7602a44 A: hmac-md5 2013c28f 56dea12f ae2835b3 654d60a2 seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Nov 4 16:43:39 2003 current: Nov 4 16:44:35 2003 diff: 56(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=0 pid=3930 refcnt=0 /sbin/setkey -D -P: 172.16.100.0/24[any] 192.168.1.0/24[any] any in ipsec esp/tunnel/44.33.44.33-66.22.66.22/require created: Nov 4 16:43:39 2003 lastused: lifetime: 0(s) validtime: 0(s) spid=8 seq=1 pid=3931 refcnt=1 192.168.1.0/24[any] 172.16.100.0/24[any] any out ipsec esp/tunnel/66.22.66.22-44.33.44.33/require created: Nov 4 16:43:39 2003 lastused: lifetime: 0(s) validtime: 0(s) spid=1 seq=0 pid=3931 refcnt=1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From jt@bougret.hpl.hp.com Tue Nov 4 15:15:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 15:16:01 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4NF625019194 for ; Tue, 4 Nov 2003 15:15:16 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id 861E31C01CEA; Tue, 4 Nov 2003 14:42:02 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_28810+JAGae91741+JAGae92668)/8.9.3 HPLabs Timeshare Server) with ESMTP id OAA24525; Tue, 4 Nov 2003 14:42:01 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1AH9s9-0003wD-00; Tue, 04 Nov 2003 14:42:01 -0800 Date: Tue, 4 Nov 2003 14:42:01 -0800 To: Arnaldo Carvalho de Melo Cc: Linux Networking Development Mailing List Subject: Re: [PATCH] fix skb leak in af_irda.c Message-ID: <20031104224201.GA15041@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20031101051931.GI3705@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031101051931.GI3705@conectiva.com.br> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 1211 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Sat, Nov 01, 2003 at 03:19:31AM -0200, Arnaldo Carvalho de Melo wrote: > Hi David, Jean, > > Please apply. > > - Arnaldo Hum... It looks as if it didn't made into the kernel. Ok, I'll add that in my patch queue and push that for you ;-) Have fun... Jean From davem@pizda.ninka.net Tue Nov 4 15:37:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 15:38:14 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4Nbe25019681 for ; Tue, 4 Nov 2003 15:37:40 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id PAA20357; Tue, 4 Nov 2003 15:30:42 -0800 Date: Tue, 4 Nov 2003 15:30:42 -0800 From: "David S. Miller" To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, acme@conectiva.com.br, netdev@oss.sgi.com Subject: Re: [PATCH] fix skb leak in af_irda.c Message-Id: <20031104153042.416b9c36.davem@redhat.com> In-Reply-To: <20031104224201.GA15041@bougret.hpl.hp.com> References: <20031101051931.GI3705@conectiva.com.br> <20031104224201.GA15041@bougret.hpl.hp.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1212 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 4 Nov 2003 14:42:01 -0800 Jean Tourrilhes wrote: > On Sat, Nov 01, 2003 at 03:19:31AM -0200, Arnaldo Carvalho de Melo wrote: > > Hi David, Jean, > > > > Please apply. > > Hum... It looks as if it didn't made into the kernel. Ok, I'll > add that in my patch queue and push that for you ;-) It isn't in because I was waiting for an acknowledgment from you Jean :-) From jt@bougret.hpl.hp.com Tue Nov 4 16:29:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 16:30:05 -0800 (PST) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA50TV25023205 for ; Tue, 4 Nov 2003 16:29:31 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id 2BCF61C016C4; Tue, 4 Nov 2003 16:29:31 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_28810+JAGae91741+JAGae92668)/8.9.3 HPLabs Timeshare Server) with ESMTP id QAA28951; Tue, 4 Nov 2003 16:29:30 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1AHBYA-0004B6-00; Tue, 04 Nov 2003 16:29:30 -0800 Date: Tue, 4 Nov 2003 16:29:30 -0800 To: "David S. Miller" Cc: acme@conectiva.com.br, netdev@oss.sgi.com Subject: Re: [PATCH] fix skb leak in af_irda.c Message-ID: <20031105002930.GA16055@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20031101051931.GI3705@conectiva.com.br> <20031104224201.GA15041@bougret.hpl.hp.com> <20031104153042.416b9c36.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031104153042.416b9c36.davem@redhat.com> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 1213 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Tue, Nov 04, 2003 at 03:30:42PM -0800, David S. Miller wrote: > On Tue, 4 Nov 2003 14:42:01 -0800 > Jean Tourrilhes wrote: > > > On Sat, Nov 01, 2003 at 03:19:31AM -0200, Arnaldo Carvalho de Melo wrote: > > > Hi David, Jean, > > > > > > Please apply. > > > > Hum... It looks as if it didn't made into the kernel. Ok, I'll > > add that in my patch queue and push that for you ;-) > > It isn't in because I was waiting for an acknowledgment > from you Jean :-) *Ahem*... Sorry about that... I personally would prefer the following patch. The difference is mostly cosmetic. Tested with 2.6.0-test9. Anyway, both patches are obviously correct. Thanks for keeping on top of those things... Jean --------------------------------------------------------- diff -u -p linux/net/irda/af_irda.d4.c linux/net/irda/af_irda.c --- linux/net/irda/af_irda.d4.c Tue Nov 4 14:37:25 2003 +++ linux/net/irda/af_irda.c Tue Nov 4 14:39:10 2003 @@ -188,8 +188,10 @@ static void irda_connect_confirm(void *i IRDA_DEBUG(2, "%s(%p)\n", __FUNCTION__, self); sk = self->sk; - if (sk == NULL) + if (sk == NULL) { + dev_kfree_skb(skb); return; + } dev_kfree_skb(skb); // Should be ??? skb_queue_tail(&sk->sk_receive_queue, skb); @@ -248,8 +250,10 @@ static void irda_connect_indication(void IRDA_DEBUG(2, "%s(%p)\n", __FUNCTION__, self); sk = self->sk; - if (sk == NULL) + if (sk == NULL) { + dev_kfree_skb(skb); return; + } /* How much header space do we need to reserve */ self->max_header_size = max_header_size; From davem@pizda.ninka.net Tue Nov 4 16:35:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 16:35:40 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA50Z625023566 for ; Tue, 4 Nov 2003 16:35:06 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA20552; Tue, 4 Nov 2003 16:28:05 -0800 Date: Tue, 4 Nov 2003 16:28:05 -0800 From: "David S. Miller" To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, acme@conectiva.com.br, netdev@oss.sgi.com Subject: Re: [PATCH] fix skb leak in af_irda.c Message-Id: <20031104162805.78d6ab4c.davem@redhat.com> In-Reply-To: <20031105002930.GA16055@bougret.hpl.hp.com> References: <20031101051931.GI3705@conectiva.com.br> <20031104224201.GA15041@bougret.hpl.hp.com> <20031104153042.416b9c36.davem@redhat.com> <20031105002930.GA16055@bougret.hpl.hp.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1214 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 4 Nov 2003 16:29:30 -0800 Jean Tourrilhes wrote: > I personally would prefer the following patch. The difference > is mostly cosmetic. Tested with 2.6.0-test9. Anyway, both patches are > obviously correct. Applied, with attribution also given to Arnaldo. Thanks. From hadi@cyberus.ca Tue Nov 4 19:01:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 19:01:48 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA531B25031739 for ; Tue, 4 Nov 2003 19:01:12 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1AHDuv-0002V8-Od; Tue, 04 Nov 2003 22:01:10 -0500 Subject: Re: Announce: NetKeeper Firewall For Linux From: jamal Reply-To: hadi@cyberus.ca To: Emmanuel Fleury Cc: "David S. Miller" , netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, Mikkel Christiansen In-Reply-To: <1067335655.10628.7.camel@rade7.s.cs.auc.dk> References: <1067285612.552.9.camel@aphrodite.olympus.net> <20031028014223.129933be.davem@redhat.com> <1067335655.10628.7.camel@rade7.s.cs.auc.dk> Content-Type: text/plain Organization: jamalopolis Message-Id: <1068001237.1064.31.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Nov 2003 22:00:37 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1215 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Hi, On Tue, 2003-10-28 at 05:07, Emmanuel Fleury wrote: > Hi, > > On Tue, 2003-10-28 at 10:42, David S. Miller wrote: > > On Mon, 27 Oct 2003 21:13:32 +0100 > > Emmanuel Fleury wrote: > > > > > For more details check out the netkeeper web-site: > > > http://www.cs.auc.dk/~fleury/netkeeper/ > > > > You may want to have a look at: > > > > http://www.cyberus.ca/~hadi/patches/action/README > > > > which I believe is the way to implement these kinds > > of things. > > Actually, that is exactly the direction which we have been aiming at. You seem to be attempting to replicate that functionalilty actually;-> (as opposed to using it). Therefore you are going to miss a lot of good things. What was posted already is just the beggining. If you want to incorporate i can send you the latest patches (posted patches have intentional bugs to see who is actually testing). You seem to be already hooking into netfilter btw so not sure how easy it would be for you; Why do you have a limit to 8 actions? BTW, since you compile your filters, how fast are you at adding rules? What about dynamic in kernel rules (such as those that may be created by contracking) - do you have to cross to user space to compile them? - Is there any reason you move the commit decision to the kernel? Could this not have been done in user space? I have doubts how fast you can install rules - which is a fundamental measure of good filters. cheers, jamal From jmorris@redhat.com Tue Nov 4 20:11:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 20:12:17 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA54BY25032610 for ; Tue, 4 Nov 2003 20:11:36 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id hA54BUM28041; Tue, 4 Nov 2003 23:11:31 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id hA54BU605569; Tue, 4 Nov 2003 23:11:30 -0500 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id hA54BT4s021573; Tue, 4 Nov 2003 23:11:29 -0500 Date: Tue, 4 Nov 2003 23:12:30 -0500 (EST) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: David T Hollis cc: Kernel Mailing List , Subject: Re: Oops in __xfrm4_state_lookup when setting up an IPSEC tunnel In-Reply-To: <3FA8245B.8030302@davehollis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1216 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev On Tue, 4 Nov 2003, David T Hollis wrote: > Both firewalls are RedHat 9 based installs, running stock 2.6.0-test9 > kernels (note the variance on bk7 and bk9). Both are running Shorewall > 1.4.7c to setup iptables/netfilter firewalling. Nothing obvious has changed between these snapshots which would cause this. Are the filtering rules the same at each gateway? Are you able to reproduce the problem without any filtering rules? > > If I configure the SAD and SPDs on gw2, than setup them up on gw1, gw2 > Oops hard on __xfrm4_state_lookup. I have not yet hand copied the > entire dump but have the initial pertinent > info: > > EIP is at __xfrm4_state_lookup+0x6f/0xa0 If you compile your kernel with -g, you should be able to find the corresponding line of code (e.g. with addr2line). - James -- James Morris From vnuorval@tcs.hut.fi Wed Nov 5 03:38:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 03:38:50 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5Bc625015018 for ; Wed, 5 Nov 2003 03:38:06 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 89CFD8001C2; Wed, 5 Nov 2003 13:02:03 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id hA5B23Gn027984; Wed, 5 Nov 2003 13:02:03 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id hA5B226R027980; Wed, 5 Nov 2003 13:02:02 +0200 Date: Wed, 5 Nov 2003 13:02:02 +0200 (EET) From: Ville Nuorvala To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] IPv6: Also fix tunnel skb->h.raw bug in ip6_tunnel.c Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1217 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Hi Dave, I noticed the skb->h.raw bug was fixed for ipip.c, ip_gre.c and sit.c, but not for ip6_tunnel.c. Here is a patch for it as well. Please apply! Thanks, Ville ===== net/ipv6/ip6_tunnel.c 1.12 vs edited ===== --- 1.12/net/ipv6/ip6_tunnel.c Sun Oct 19 10:12:04 2003 +++ edited/net/ipv6/ip6_tunnel.c Wed Nov 5 09:48:13 2003 @@ -681,7 +681,6 @@ icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, dev); goto tx_err_dst_release; } - skb->h.raw = skb->nh.raw; /* * Okay, now see if we can stuff it in the buffer as-is. @@ -702,6 +701,8 @@ } dst_release(skb->dst); skb->dst = dst_clone(dst); + + skb->h.raw = skb->nh.raw; if (opt) ipv6_push_nfrag_opts(skb, opt, &proto, NULL); -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From vnuorval@tcs.hut.fi Wed Nov 5 04:11:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 04:12:21 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5CBQ25017147 for ; Wed, 5 Nov 2003 04:11:30 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id AC6AB800217; Wed, 5 Nov 2003 13:35:33 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id hA5BZXGn028096; Wed, 5 Nov 2003 13:35:33 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id hA5BZXvh028092; Wed, 5 Nov 2003 13:35:33 +0200 Date: Wed, 5 Nov 2003 13:35:33 +0200 (EET) From: Ville Nuorvala To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] IPv6: Flowinfo fix in ip6_tunnel.c Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1218 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Hi Dave, would you also apply this minor patch? This makes the handling of flowlabels consistent with the way flowlabels are passed from userspace using sockopts. Thanks, Ville ===== net/ipv6/ip6_tunnel.c 1.13 vs edited ===== --- 1.13/net/ipv6/ip6_tunnel.c Wed Nov 5 09:52:58 2003 +++ edited/net/ipv6/ip6_tunnel.c Wed Nov 5 10:01:12 2003 @@ -810,9 +810,9 @@ fl->fl6_flowlabel = 0; if (!(p->flags&IP6_TNL_F_USE_ORIG_TCLASS)) - fl->fl6_flowlabel |= IPV6_TCLASS_MASK & htonl(p->flowinfo); + fl->fl6_flowlabel |= IPV6_TCLASS_MASK & p->flowinfo; if (!(p->flags&IP6_TNL_F_USE_ORIG_FLOWLABEL)) - fl->fl6_flowlabel |= IPV6_FLOWLABEL_MASK & htonl(p->flowinfo); + fl->fl6_flowlabel |= IPV6_FLOWLABEL_MASK & p->flowinfo; ip6_tnl_set_cap(t); -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From vnuorval@tcs.hut.fi Wed Nov 5 05:07:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 05:08:10 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5D7Z25021413 for ; Wed, 5 Nov 2003 05:07:36 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 8CC50800211; Wed, 5 Nov 2003 15:07:34 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id hA5D7YGn028364; Wed, 5 Nov 2003 15:07:34 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id hA5D7XmG028360; Wed, 5 Nov 2003 15:07:34 +0200 Date: Wed, 5 Nov 2003 15:07:32 +0200 (EET) From: Ville Nuorvala To: yoshfuji@linux-ipv6.org Cc: davem@redhat.com, netdev@oss.sgi.com Subject: [PATCH] IPv6: Autoconfig link-local address on ip6-ip6 tunnel device Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1219 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Hello Yoshifuji-san, this (rewritten) patch configures link-local addresses to the ip6-ip6 tunnel devices so you can run link-local protocols over them. If you are ok with the patch, perhaps we could push it forward to Dave. Thanks, Ville ===== net/ipv6/addrconf.c 1.74 vs edited ===== --- 1.74/net/ipv6/addrconf.c Tue Oct 28 13:10:47 2003 +++ edited/net/ipv6/addrconf.c Wed Nov 5 14:50:29 2003 @@ -1818,6 +1818,58 @@ sit_route_add(dev); } +#if defined(CONFIG_IPV6_TUNNEL) || defined(CONFIG_IPV6_TUNNEL_MODULE) + +static inline int +ip6_tnl_inherit_linklocal(struct inet6_dev *idev, struct net_device *link_dev) +{ + struct in6_addr lladdr; + + if (!ipv6_get_lladdr(link_dev, &lladdr)) { + addrconf_add_linklocal(idev, &lladdr); + return 0; + } + return -1; +} + +static void ip6_tnl_add_linklocal(struct inet6_dev *idev) +{ + struct net_device *link_dev; + + /* first try to inherit the link-local address from the link device */ + if (idev->dev->iflink && + (link_dev = __dev_get_by_index(idev->dev->iflink))) { + if (!ip6_tnl_inherit_linklocal(idev, link_dev)) + return; + } + /* then try to inherit it from any device */ + for (link_dev = dev_base; link_dev; link_dev = link_dev->next) { + if (!ip6_tnl_inherit_linklocal(idev, link_dev)) + return; + } + printk(KERN_DEBUG "init ip6-ip6: add_linklocal failed\n"); +} + +/* + * Autoconfigure tunnel with a link-local address so routing protocols, + * DHCPv6, MLD etc. can be run over the virtual link + */ + +static void addrconf_ip6_tnl_config(struct net_device *dev) +{ + struct inet6_dev *idev; + + ASSERT_RTNL(); + + if ((idev = addrconf_add_dev(dev)) == NULL) { + printk(KERN_DEBUG "init ip6-ip6: add_dev failed\n"); + return; + } + ip6_tnl_add_linklocal(idev); + addrconf_add_mroute(dev); +} +#endif + int addrconf_notify(struct notifier_block *this, unsigned long event, void * data) @@ -1831,7 +1883,11 @@ case ARPHRD_SIT: addrconf_sit_config(dev); break; - +#if defined(CONFIG_IPV6_TUNNEL) || defined(CONFIG_IPV6_TUNNEL_MODULE) + case ARPHRD_TUNNEL6: + addrconf_ip6_tnl_config(dev); + break; +#endif case ARPHRD_LOOPBACK: init_loopback(dev); break; ===== net/ipv6/ip6_tunnel.c 1.14 vs edited ===== --- 1.14/net/ipv6/ip6_tunnel.c Wed Nov 5 10:11:00 2003 +++ edited/net/ipv6/ip6_tunnel.c Wed Nov 5 14:58:27 2003 @@ -821,6 +821,8 @@ else dev->flags &= ~IFF_POINTOPOINT; + dev->iflink = p->link; + if (p->flags & IP6_TNL_F_CAP_XMIT) { struct rt6_info *rt = rt6_lookup(&p->raddr, &p->laddr, p->link, 0); @@ -829,8 +831,6 @@ return; if (rt->rt6i_dev) { - dev->iflink = rt->rt6i_dev->ifindex; - dev->hard_header_len = rt->rt6i_dev->hard_header_len + sizeof (struct ipv6hdr); @@ -1040,7 +1040,6 @@ dev->hard_header_len = LL_MAX_HEADER + sizeof (struct ipv6hdr); dev->mtu = ETH_DATA_LEN - sizeof (struct ipv6hdr); dev->flags |= IFF_NOARP; - dev->iflink = 0; dev->addr_len = sizeof(struct in6_addr); } -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From hadi@znyx.com Wed Nov 5 06:54:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 06:54:59 -0800 (PST) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5EsP25022911 for ; Wed, 5 Nov 2003 06:54:25 -0800 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003110506531276:3436 ; Wed, 5 Nov 2003 06:53:12 -0800 Subject: Re: Fw: issues with SO_PRIORITY and IP_TOS From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Chris Friesen Cc: Alexey , "David S. Miller" , jmorris@redhat.com, netdev@oss.sgi.com In-Reply-To: <3FA7DBB5.1090500@nortelnetworks.com> References: <200311041233.PAA15518@yakov.inr.ac.ru> <3FA7DBB5.1090500@nortelnetworks.com> Organization: Znyx Networks Message-Id: <1068044059.1022.0.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Nov 2003 09:54:22 -0500 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/05/2003 06:53:13 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/05/2003 06:53:14 AM, Serialize complete at 11/05/2003 06:53:14 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 1220 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev On Tue, 2003-11-04 at 12:02, Chris Friesen wrote: > > I do not even think that IP_DSCP makes sense in diffserv environment. > > Packets are marked according to DS rules, not according to desire > > of particular user. > > If root wants to send out a packet with particular DSCP settings, > doesn't it make sense to make that option available? It's a field in > the IP packet header, we should be able to set it with an IP option. > Just to give you some history: This topic has been discussed to death in the past. Look at the diffserv mailing lists. Common practise is that the network manager controls the DSCP. They _never_ trust the user. Of course this gives a lot of power to network managers and router vendors such as nortel. But these guys own the network. Qos is a way for them to make more money from different services. The only OS vendor that made noise on this was MS. And they lost too. I think thye now have a diffserv API which is not different from what we have on tc. BTW, i would worry about the vlan 802.1p QoS settings. While they may appear to give you QoS within the box, once those bits start crossing the network with switches that do 802.1q/p you may find that the result is the opposite. cheers, jamal From fleury@cs.auc.dk Wed Nov 5 07:30:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 07:31:22 -0800 (PST) Received: from mailhost.cs.auc.dk (root@mailhost.cs.auc.dk [130.225.194.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5FUO25023725 for ; Wed, 5 Nov 2003 07:30:45 -0800 Received: from rade7.s.cs.auc.dk (fleury@rade7.s.cs.auc.dk [192.168.194.153]) by mailhost.cs.auc.dk (8.12.10/8.12.10) with ESMTP id hA5FTKlN023255; Wed, 5 Nov 2003 16:29:20 +0100 (MET) Subject: Re: Announce: NetKeeper Firewall For Linux From: Emmanuel Fleury To: hadi@cyberus.ca Cc: "David S. Miller" , netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, Mikkel Christiansen In-Reply-To: <1068001237.1064.31.camel@jzny.localdomain> References: <1067285612.552.9.camel@aphrodite.olympus.net> <20031028014223.129933be.davem@redhat.com> <1067335655.10628.7.camel@rade7.s.cs.auc.dk> <1068001237.1064.31.camel@jzny.localdomain> Content-Type: text/plain; charset=iso-8859-15 Organization: Aalborg University -- Computer Science Dept. Message-Id: <1068046114.31636.92.camel@rade7.s.cs.auc.dk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 05 Nov 2003 16:28:34 +0100 X-Scanned-By: MIMEDefang 2.14 X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.cs.auc.dk id hA5FTKlN023255 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hA5FUO25023725 X-archive-position: 1221 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fleury@cs.auc.dk Precedence: bulk X-list: netdev Hi, On Wed, 2003-11-05 at 04:00, jamal wrote: > > You seem to be attempting to replicate that functionality actually;-> > (as opposed to using it). Therefore you are going to miss a lot of > good things. What was posted already is just the beggining. I'm not sure it is the case (but I might have missed the point). My first answer to David S. Miller was probably misleading. What we are trying to do is to investigate an alternate algorithm to do packet classification. Our overall goal is not to produce a shiny tool that goes into Linux, but a new scheme which is more scalable than the one that everybody is using right now (i.e. the "world famous" classification based on rulesets). If our scheme can be useful and is, at some point, included in one existing tool, I would be the first one to take the netkeeper code and put it to the trash (as it serve only to demonstrate and tune our scheme). So do not consider us as "yet another concurrent project to fight with", because we are not really aiming at the same thing. :) > If you want to incorporate i can send you the latest patches (posted > patches have intentional bugs to see who is actually testing). You > seem to be already hooking into netfilter btw so not sure how easy it > would be for you; Anyway, reading some new code can give us nice ideas. We would be pleased to see what you've already achieved. > Why do you have a limit to 8 actions? This limit is totally artificial. Basically, the story is that we had a union in a struct and we filled up the memory space with these actions so that no memory was left behind. We decided (on arbitrary basis) that nobody would attach more than 8 different actions to a precise packet. We also though that having 256 different actions would be enough. In fact, these two limits (8 and 256) are totally artificial and have been introduced in our prototype just because it was "convenient". We can extend the list of actions by using a chained list and code the actions on a bigger variable than a byte. > BTW, since you compile your filters, how fast are you at adding rules? So, here, you are hitting the sensitive spot ! In fact, we are totally ignorant of what are the requirements on these dynamic updates in networking. So any discussion about this is extremely valuable for us. For your question, the theory (and the practice) is telling us that the time to add a new rule to an existing ruleset depend essentially of the complexity of the already existing ruleset. Don't miss my point, the number of rules which compose the ruleset is not the only parameter. Because, as your are going through an optimization a ruleset with a lot of trivial rules is simplified and will be trivial at the end. Therefore, it essentially depend on the ruleset to which you are adding your new rule. But, we still have to work on this part. The way we have coded the compiler is very simple and we have already some ideas on how to optimize it. Actually, a good thing for us would be to know what are your expectation in matter of adding a new rule. What is "acceptable" and what is "not". And, now, some tables with numbers: +--------+---------+-------+-------+----------+ | #rules | time(s) | nodes | edges | size(KB) | +--------+---------+-------+-------+----------+ | 10 | 0.01 | 28 | 102 | 1.584 | | 25 | 0.03 | 77 | 279 | 4.296 | | 50 | 0.11 | 128 | 481 | 7.332 | | 100 | 0.44 | 232 | 891 | 13.500 | | 250 | 3.44 | 542 | 2109 | 31.836 | | 500 | 19.14 | 998 | 3952 | 59.424 | | 1,000 | 37.72 | 1884 | 7544 | 113.160 | | 2,500 | 102.1 | 4289 | 17493 | 261.408 | | 5,000 | 237.0 | 7678 | 31880 | 474.720 | | 10,000 | 571.4 | 13420 | 57417 | 850.068 | | 25,000 | 1832.0 | 24657 |116673 | 1695.984 | | 50,000 | 5221.0 | 37416 |198754 | 2834.064 | +--------+---------+-------+-------+----------+ The rulesets considered here are totally artificially generated and are matching our worst case in term of computing time. Of course your question was about taking one of this big filters and then add one tiny winny rule to it. So, I guess the time to do so would be at most 1s (in the very worst case, I would say). > What about dynamic in kernel rules (such as those that may be created > by contracking) - do you have to cross to user space to compile them? We have some ideas on how to handle it. But for now, the scheme is totally static. I would say that we are keeping this area of research (stateful inspection) for later. :) > - Is there any reason you move the commit decision to the kernel? > Could this not have been done in user space? Yes, definitely. When coding in the kernel, we are coding with the idea that: « The kernel should defend itself against user-space. » So, when the user say: "Commit". The kernel will first check the decision diagram for safety (no NULL pointers, out of range variables, no loops, etc) and depending of the tests, will take the decision to commit or not. Actually, I think I read some stuff about it on the Netfilter-devel mailing-list. As far as I remember, there was a similar problem in netfilter as the safety of the whole thing is never really tested in depth. Therefore you can end-up with some loops or inconsistancy (WARNING: I'm not sure about it!). > I have doubts how fast you can install rules - which is a fundamental > measure of good filters. The fact is that theory is saying that optimizing is a complex problem (but it still has a polynomial time complexity ). But, we can for sure improve A LOT our current tools. The problem for us is that we do not know against what we are fighting ! We really need some hints on how fast should be this operation (just to see if it is possible or not in our scheme). PS: I would like also to say here that we got a really great feed back from the nf-hipac team. So, thank a lot to Michael Bellion and Thomas Heinz. Regards -- Emmanuel Netkeeper (An IDD firewall) http://www.cs.auc.dk/~fleury/netkeeper/ From s0348365@sms.ed.ac.uk Wed Nov 5 08:59:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 08:59:42 -0800 (PST) Received: from grassmarket.ucs.ed.ac.uk (grassmarket.ucs.ed.ac.uk [129.215.166.64]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5Gx625028556 for ; Wed, 5 Nov 2003 08:59:07 -0800 Received: from 10.22.0.132 ([10.22.0.132]) by grassmarket.ucs.ed.ac.uk (8.12.10/8.12.9) with ESMTP id hA5GwvM3004527; Wed, 5 Nov 2003 16:58:58 GMT From: Alistair John Strachan To: Andrew Morton Subject: Re: 2.6.0-test9-mm2 Date: Wed, 5 Nov 2003 17:02:00 +0000 User-Agent: KMail/1.5.93 References: <20031104225544.0773904f.akpm@osdl.org> In-Reply-To: <20031104225544.0773904f.akpm@osdl.org> Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, netdev@oss.sgi.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200311051702.00372.s0348365@sms.ed.ac.uk> X-archive-position: 1222 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: s0348365@sms.ed.ac.uk Precedence: bulk X-list: netdev On Wednesday 05 November 2003 06:55, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2 >.6.0-test9-mm2/ > > > - Various random fixes. Maybe about half of these are 2.6.0-worthy. > > - Some improvements to the anticipatory IO scheduler and more readahead > tweaks should help some of those database benchmarks. > > The anticipatory scheduler is still a bit behind the deadline scheduler > in these random seeky loads - it most likely always will be. > > - "A new driver for the ethernet interface of the NVIDIA nForce chipset, > licensed under GPL." > > Testing of this would be appreciated. Send any reports to linux-kernel > or netdev@oss.sgi.com and Manfred will scoop them up, thanks. > I tried the force driver on my nForce2 machine and although it mostly works (DHCP works, I can receive mail over the interface, etc..) it doesn't seem to handle really bulky loads. For example, I'm running an FTP server on the machine (proftpd), and although FTP navigation works just fine, transferring large files just causes the transfer to hang indefinitely. Removing the driver and using NVIDIA's proprietary driver allows me to transfer via FTP properly. -- Cheers, Alistair. personal: alistair()devzero!co!uk university: s0348365()sms!ed!ac!uk student: CS/AI Undergraduate contact: 7/10 Darroch Court, University of Edinburgh. From yoshfuji@linux-ipv6.org Wed Nov 5 09:28:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 09:29:12 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5HSc25029128 for ; Wed, 5 Nov 2003 09:28:39 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-6.6) with ESMTP id hA5HSmlg009365; Thu, 6 Nov 2003 02:28:49 +0900 Date: Thu, 06 Nov 2003 02:28:48 +0900 (JST) Message-Id: <20031106.022848.02505922.yoshfuji@linux-ipv6.org> To: davem@redhat.com CC: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Fw: why is mode of /proc/sys/net/ipv6/icmp directory only 0500? From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Nov__6_02:28:48_2003_499)--" Content-Transfer-Encoding: 7bit X-archive-position: 1223 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev ----Next_Part(Thu_Nov__6_02:28:48_2003_499)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit David, please apply this. I don't see any reason to keep it 0500. Thanks. ----Next_Part(Thu_Nov__6_02:28:48_2003_499)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from cerberus.hongo.wide.ad.jp (root@cerberus.hongo.wide.ad.jp [203.178.139.93]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-6.6) with ESMTP id hA5HHalg009324 for ; Thu, 6 Nov 2003 02:17:36 +0900 Received: from linux6.nezu.wide.ad.jp (linux6.nezu.wide.ad.jp [203.178.142.218]) by cerberus.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-6.6) with ESMTP id hA5HHO4x014830 for ; Thu, 6 Nov 2003 02:17:24 +0900 Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by linux6.nezu.wide.ad.jp (8.12.3/8.12.3/Debian-6.6) with ESMTP id hA5HHMF1000551 for ; Thu, 6 Nov 2003 02:17:23 +0900 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id hA5HHHWB027535 for ; Wed, 5 Nov 2003 12:17:21 -0500 Message-Id: <200311051717.hA5HHHWB027535@ginger.lcs.mit.edu> From: Tim Shepard To: yoshfuji@linux-ipv6.org Subject: why is mode of /proc/sys/net/ipv6/icmp directory only 0500? Date: Wed, 05 Nov 2003 12:17:17 -0500 Sender: shep@ginger.lcs.mit.edu MIME-Version: 1.0 I did a google search to find why the mode of the /proc/sys/net/ipv6/icmp directory is only 0500 and found that it originates in a patch of yours: http://lwn.net/Articles/13656/ Why not have mode 0555, like this patch below? If not 0555, then IMHO there needs to be a comment that justifies 0500. -Tim Shepard --- net/ipv6/sysctl_net_ipv6.c.DIST 2003-10-25 14:42:54.000000000 -0400 +++ net/ipv6/sysctl_net_ipv6.c 2003-11-05 12:10:34.000000000 -0500 @@ -22,25 +22,25 @@ ctl_table ipv6_table[] = { { .ctl_name = NET_IPV6_ROUTE, .procname = "route", .maxlen = 0, .mode = 0555, .child = ipv6_route_table }, { .ctl_name = NET_IPV6_ICMP, .procname = "icmp", .maxlen = 0, - .mode = 0500, + .mode = 0555, .child = ipv6_icmp_table }, { .ctl_name = NET_IPV6_BINDV6ONLY, .procname = "bindv6only", .data = &sysctl_ipv6_bindv6only, .maxlen = sizeof(int), .mode = 0644, .proc_handler = &proc_dointvec }, { .ctl_name = NET_IPV6_IP6FRAG_HIGH_THRESH, ----Next_Part(Thu_Nov__6_02:28:48_2003_499)---- From modica@sgi.com Wed Nov 5 10:03:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 10:04:25 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5I3q25006290 for ; Wed, 5 Nov 2003 10:03:52 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA5I3kq0022788 for ; Wed, 5 Nov 2003 10:03:47 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA5I3kP513174002 for ; Wed, 5 Nov 2003 12:03:46 -0600 (CST) Received: from sgi.com (eagdhcp-232-154.americas.sgi.com [128.162.232.154]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA5I3jRn352140039 for ; Wed, 5 Nov 2003 12:03:46 -0600 (CST) Message-ID: <3FA93B82.5070508@sgi.com> Date: Wed, 05 Nov 2003 12:03:46 -0600 From: Steve Modica Organization: SGI User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: High interrupt rate even when using NAPI Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1224 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: modica@sgi.com Precedence: bulk X-list: netdev Hi All, I just noticed some strange behavior with the tg3 driver. Even with NAPI enabled, during high loads of 1500 byte MTUS, I'm seeing a very high interrupt rate. To move 500kBytes/sec I'm seeing 22k interrupts/sec. It tracks very closely with the actualy throughput. That amounts to about 1 interrupt per 23 bytes. I figured with NAPI, we should do a lot better than that. Is there a tuneable or some driver stat that I can track to figure out what's happening here? I'd like to see that interrupt number be a lot lower. Steve -- Steve Modica MTS-Technical Lead "Give a man a fish, and he will eat for a day, hit him with a fish and he leaves you alone" - me From davem@pizda.ninka.net Wed Nov 5 10:13:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 10:13:35 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5ID225024324 for ; Wed, 5 Nov 2003 10:13:03 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id KAA03636; Wed, 5 Nov 2003 10:07:51 -0800 Date: Wed, 5 Nov 2003 10:07:50 -0800 From: "David S. Miller" To: Steve Modica Cc: netdev@oss.sgi.com Subject: Re: High interrupt rate even when using NAPI Message-Id: <20031105100750.63974931.davem@redhat.com> In-Reply-To: <3FA93B82.5070508@sgi.com> References: <3FA93B82.5070508@sgi.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1225 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 05 Nov 2003 12:03:46 -0600 Steve Modica wrote: > I just noticed some strange behavior with the tg3 driver. The tg3 driver needs to poke the chip a hundred times per second in order to work around a hardware bug, eack poke causes an interrupt. This is needed regardless of whether the chip is processing packets or not. From romieu@fr.zoreil.com Wed Nov 5 10:39:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 10:39:51 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5IdD25025119 for ; Wed, 5 Nov 2003 10:39:14 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id hA5IY8Jo012800; Wed, 5 Nov 2003 19:34:08 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id hA5IY0Km012799; Wed, 5 Nov 2003 19:34:00 +0100 Date: Wed, 5 Nov 2003 19:34:00 +0100 From: Francois Romieu To: "Alexandra N. Kossovsky" Cc: linux-kernel@vger.kernel.org, ShuChen , netdev@oss.sgi.com Subject: Re: r8169 with big-endian (patch) Message-ID: <20031105193400.A12375@electric-eye.fr.zoreil.com> References: <20031105104625.D26209@oktet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031105104625.D26209@oktet.ru>; from sasha@oktet.ru on Wed, Nov 05, 2003 at 10:46:26AM +0300 X-Organisation: Land of Sunshine Inc. X-archive-position: 1226 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Greetings, Alexandra N. Kossovsky : [...] > Here is the patch to make RTL-8169 PCI Gbit ethernet card to work with > big-endian host. The patch is against 2.4.22 kernel. Please Cc: such patches to netdev@oss.sgi.com as well as jgarzik@pobox.com. [...] > @@ -664,19 +675,21 @@ > } > > tp->TxDescArrays = > - kmalloc(NUM_TX_DESC * sizeof (struct TxDesc) + 256, GFP_KERNEL); > + pci_alloc_consistent(tp->pci_dev, > + NUM_TX_DESC * sizeof (struct TxDesc) + 256, > + &tp->TxDescDmaAddrs); > - TxPhyAddr = virt_to_bus(tp->TxDescArrays); > - diff = 256 - (TxPhyAddr - ((TxPhyAddr >> 8) << 8)); > - TxPhyAddr += diff; > + diff = 256 - (tp->TxDescDmaAddrs - ((tp->TxDescDmaAddrs >> 8) << 8)); > + tp->TxDescDmaAddr = tp->TxDescDmaAddrs + diff; > tp->TxDescArray = (struct TxDesc *) (tp->TxDescArrays + diff); Remove the alignment stuff. pci_alloc_consistent() does it for you, see Documentation/DMA-mapping.txt: [...] The cpu return address and the DMA bus master address are both guaranteed to be aligned to the smallest PAGE_SIZE order which is greater than or equal to the requested size. This invariant @@ -684,12 +697,18 @@ [...] - tp->RxBufferRings = kmalloc(RX_BUF_SIZE * NUM_RX_DESC, GFP_KERNEL); + tp->RxBufferRings = pci_alloc_consistent(tp->pci_dev, + RX_BUF_SIZE * NUM_RX_DESC, + &tp->RxBufferDmas); You don't want consistent mapping for the data buffer. Either you pci_map_single() the whole kmalloced() area and you sync it when needed or you turn this code into usual, per skb, pci_map_single() calls and you remove the big Rx data buffer. -- Ueimor From masterpe@xs4all.nl Wed Nov 5 11:04:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 11:04:43 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5J4825025881 for ; Wed, 5 Nov 2003 11:04:09 -0800 Received: from lawbox.int.mpe.xs4all.nl (mpe.xs4all.nl [213.84.237.99]) by smtpzilla2.xs4all.nl (8.12.9/8.12.9) with ESMTP id hA5J45NY013585 for ; Wed, 5 Nov 2003 20:04:06 +0100 (CET) Subject: Report on the forcedeth driver From: Laurens To: netdev@oss.sgi.com Content-Type: text/plain Message-Id: <1068059045.3618.3.camel@lawbox.int.mpe.xs4all.nl> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 05 Nov 2003 20:04:05 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 1227 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: masterpe@xs4all.nl Precedence: bulk X-list: netdev I tested the new driver as was requested and it works properly. I'm sending this to you now using the forcedeth module. Only note I have is that dhcpcd eth0 takes significantly longer to load then with nvnet. So as far as I'm concerned speed is the only "issue". good luck, Lawrence From davem@pizda.ninka.net Wed Nov 5 12:31:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 12:32:10 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5KVa25030680 for ; Wed, 5 Nov 2003 12:31:37 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA04293; Wed, 5 Nov 2003 12:26:31 -0800 Date: Wed, 5 Nov 2003 12:26:31 -0800 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: Fw: why is mode of /proc/sys/net/ipv6/icmp directory only 0500? Message-Id: <20031105122631.10112a14.davem@redhat.com> In-Reply-To: <20031106.022848.02505922.yoshfuji@linux-ipv6.org> References: <20031106.022848.02505922.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1228 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 06 Nov 2003 02:28:48 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > David, please apply this. > I don't see any reason to keep it 0500. Applied, thank you. From davem@pizda.ninka.net Wed Nov 5 12:40:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 12:40:48 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5KeF25031101 for ; Wed, 5 Nov 2003 12:40:15 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA04336; Wed, 5 Nov 2003 12:34:08 -0800 Date: Wed, 5 Nov 2003 12:34:08 -0800 From: "David S. Miller" To: Ville Nuorvala Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPv6: Also fix tunnel skb->h.raw bug in ip6_tunnel.c Message-Id: <20031105123408.5db4d1ec.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1229 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 5 Nov 2003 13:02:02 +0200 (EET) Ville Nuorvala wrote: > I noticed the skb->h.raw bug was fixed for ipip.c, ip_gre.c and sit.c, but > not for ip6_tunnel.c. Here is a patch for it as well. Please apply! Applied, thanks Ville. From bcwhite@precidia.com Wed Nov 5 12:41:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 12:41:39 -0800 (PST) Received: from mx2.magma.ca (mx2.magma.ca [206.191.0.250]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5Kf325031132 for ; Wed, 5 Nov 2003 12:41:06 -0800 Received: from mail2.magma.ca (mail2.magma.ca [206.191.0.214]) by mx2.magma.ca Magma's Mail Server with ESMTP id hA5Kf2O0029024 for ; Wed, 5 Nov 2003 15:41:02 -0500 Received: from ottgate.precidia.com (ottgate.precidia.com [206.191.32.162]) by mail2.magma.ca (8.12.10/8.12.9) with ESMTP id hA5Kf2kJ018867 for ; Wed, 5 Nov 2003 15:41:02 -0500 Received: from tolkien.ott.precidia.com [10.0.1.2] (mail) by ottgate.precidia.com with esmtp (Exim 3.35 #1 (Debian)) id 1AHUSc-0001BT-00; Wed, 05 Nov 2003 15:41:02 -0500 Received: from adams.ott.precidia.com (precidia.com) [10.0.2.138] by tolkien.ott.precidia.com with esmtp (Exim 3.35 #1 (Debian)) id 1AHUSc-0000HP-00; Wed, 05 Nov 2003 15:41:02 -0500 Message-ID: <3FA9605E.2876B0D5@precidia.com> Date: Wed, 05 Nov 2003 15:41:02 -0500 From: Brian White Organization: Precidia Technologies http://www.precidia.com/ X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: rp_filter dropping things it shouldn't Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1230 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bcwhite@precidia.com Precedence: bulk X-list: netdev Kernel: 2.4.20 Arch: i386 Dist: debian/testing While experimenting with an automatic dial-backup system, we ended up with the situation where we have two default routes, one to PPP with a metric of 0 and one to ethernet with a metric of 1. The PPP route is brought on-line when connectivity to a remote host is not possible over ethernet but the default route over eth0 needs to remain so we can continue to check that link. The problem is that when we bind to eth0 to ping the remote host and a reply does come back (thus indicating we can close the dial-backup link), the ping reply is getting dropped by "rp_filter". My guess is that rp_filter sees that the preferred default route is over ppp0 and thus assumes that packets should not be coming over eth0, which of course they do since that is the interface/address the request was sent from. Setting "rp_filter" to "0" for "eth0" fixed this problem. Brian ( bcwhite@precidia.com ) ------------------------------------------------------------------------------- "A dollar saved is two dollars earned." -- Dave Chilton (The Wealthy Barber) From davem@pizda.ninka.net Wed Nov 5 12:41:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 12:41:48 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5KfF25031173 for ; Wed, 5 Nov 2003 12:41:15 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA04356; Wed, 5 Nov 2003 12:35:08 -0800 Date: Wed, 5 Nov 2003 12:35:08 -0800 From: "David S. Miller" To: Ville Nuorvala Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPv6: Flowinfo fix in ip6_tunnel.c Message-Id: <20031105123508.20599fc6.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1231 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 5 Nov 2003 13:35:33 +0200 (EET) Ville Nuorvala wrote: > would you also apply this minor patch? This makes the handling of > flowlabels consistent with the way flowlabels are passed from userspace > using sockopts. This looks fine, applied thanks. From modica@sgi.com Wed Nov 5 12:41:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 12:42:26 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5Kfq25031361 for ; Wed, 5 Nov 2003 12:41:52 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA5IlGOO014881 for ; Wed, 5 Nov 2003 10:47:16 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA5KfkP513155175 for ; Wed, 5 Nov 2003 14:41:46 -0600 (CST) Received: from sgi.com (eagdhcp-232-154.americas.sgi.com [128.162.232.154]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA5KfkRn347449038 for ; Wed, 5 Nov 2003 14:41:46 -0600 (CST) Message-ID: <3FA9608A.1020706@sgi.com> Date: Wed, 05 Nov 2003 14:41:46 -0600 From: Steve Modica Organization: SGI User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: High interrupt rate on tg3 driver Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1232 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: modica@sgi.com Precedence: bulk X-list: netdev Hi All, It turns out that there's a hardware bug that can cause a missed interrupt with the 570X chipset. So the tg3 driver will poke the card every 10msec to make sure we don't miss one. Each of these pokes generates an interrupt. However this still doesn't explain the high interrupt rate I'm seeing. I'm seeing about 22k/sec when moving 500kBytes/sec of data. I've got 5 cards ports on the system, so I can account for 500/sec, and I could even see each NAPI interrupt/poll cycle generating a few hundred a sec, but 22000 seems like way too many. Can anyone think of a real good way to capture this? Profiling just shows me spending a lot of time in tg3_poll, do_csum and memcpy. Steve -- Steve Modica work: 651-683-3224 MTS-Technical Lead "Give a man a fish, and he will eat for a day, hit him with a fish and he leaves you alone" - me From davem@pizda.ninka.net Wed Nov 5 12:59:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 13:00:28 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5Kxn25000643 for ; Wed, 5 Nov 2003 12:59:50 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA04429; Wed, 5 Nov 2003 12:53:42 -0800 Date: Wed, 5 Nov 2003 12:53:42 -0800 From: "David S. Miller" To: Ville Nuorvala Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] IPv6: Autoconfig link-local address on ip6-ip6 tunnel device Message-Id: <20031105125342.7e7e2ee9.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1233 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 5 Nov 2003 15:07:32 +0200 (EET) Ville Nuorvala wrote: > If you are ok with the patch, perhaps we could push it forward to Dave. When a decision is made about this patch, just let me know. Thanks. From jgarzik@pobox.com Wed Nov 5 13:37:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 13:37:40 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5Law25001772 for ; Wed, 5 Nov 2003 13:36:59 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:35237 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 1AHVKi-00088L-Nd; Wed, 05 Nov 2003 21:36:56 +0000 Message-ID: <3FA96D68.4090806@pobox.com> Date: Wed, 05 Nov 2003 16:36:40 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: Pekka Pietikainen , netdev@oss.sgi.com Subject: Re: changing MTU on b44 breaks eth0 References: <1067888106.3366.20.camel@bluez.bueche.ch> <20031103205335.GA7668@ee.oulu.fi> <20031103151618.79704b30.davem@redhat.com> <20031104111555.GA26860@ee.oulu.fi> <20031104091355.70d6a3d1.davem@redhat.com> <20031104211937.GA3888@ee.oulu.fi> <20031104132017.1d43a69c.davem@redhat.com> In-Reply-To: <20031104132017.1d43a69c.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1234 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev David S. Miller wrote: > On Tue, 4 Nov 2003 23:19:37 +0200 > Pekka Pietikainen wrote: > > >>On Tue, Nov 04, 2003 at 09:13:55AM -0800, David S. Miller wrote: >> >>>free_netdev() is being invoked before the device registration >>>state advanced to NETREG_UNREGISTERED, likely unregister_netdev() >>>has not been called first or a bogus pointer was passed into >>>the routine. >> >>Ah, like a missing SET_NETDEV_DEV? :-) > > > Wonderful, Jeff please integrate this b44 patch from Pekka. If someone can send me the latest patch, certainly! :) There wasn't a patch appended to this message I'm replying to, nor did any of the patches I saw on netdev include a SET_NETDEV_DEV change... Jeff From davem@pizda.ninka.net Wed Nov 5 13:41:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 13:41:49 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5LfF25002570 for ; Wed, 5 Nov 2003 13:41:15 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id NAA04622; Wed, 5 Nov 2003 13:35:17 -0800 Date: Wed, 5 Nov 2003 13:35:16 -0800 From: "David S. Miller" To: Jeff Garzik Cc: pp@ee.oulu.fi, netdev@oss.sgi.com Subject: Re: changing MTU on b44 breaks eth0 Message-Id: <20031105133516.289a62b9.davem@redhat.com> In-Reply-To: <3FA96D68.4090806@pobox.com> References: <1067888106.3366.20.camel@bluez.bueche.ch> <20031103205335.GA7668@ee.oulu.fi> <20031103151618.79704b30.davem@redhat.com> <20031104111555.GA26860@ee.oulu.fi> <20031104091355.70d6a3d1.davem@redhat.com> <20031104211937.GA3888@ee.oulu.fi> <20031104132017.1d43a69c.davem@redhat.com> <3FA96D68.4090806@pobox.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1235 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 05 Nov 2003 16:36:40 -0500 Jeff Garzik wrote: > If someone can send me the latest patch, certainly! :) > > There wasn't a patch appended to this message I'm replying to, nor did > any of the patches I saw on netdev include a SET_NETDEV_DEV change... The most recent one did, I'll forward to you under seperate cover. From jmorris@redhat.com Wed Nov 5 15:18:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 15:18:55 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5NI425007828 for ; Wed, 5 Nov 2003 15:18:21 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id hA5NI3M11120 for ; Wed, 5 Nov 2003 18:18:03 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id hA5NI3605106 for ; Wed, 5 Nov 2003 18:18:03 -0500 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id hA5NI24s008708 for ; Wed, 5 Nov 2003 18:18:02 -0500 Date: Wed, 5 Nov 2003 18:19:05 -0500 (EST) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: netdev@oss.sgi.com Subject: Re: Oops in __xfrm4_state_lookup when setting up an IPSEC tunnel (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1236 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Here is some better debug info, also, he was able to resolve the issue by fixing his policy (previously posted to lkml), so it looks like a bug to be investigated. ---------- Forwarded message ---------- Date: Wed, 05 Nov 2003 10:26:58 -0500 From: David T Hollis To: James Morris Cc: David S. Miller Subject: Re: Oops in __xfrm4_state_lookup when setting up an IPSEC tunnel James Morris wrote: >On Wed, 5 Nov 2003, David T Hollis wrote: > > > > >>>>EIP is at __xfrm4_state_lookup+0x6f/0xa0 >>>> >>>> >>>> >>>> >>>If you compile your kernel with -g, you should be able to find the >>>corresponding line of code (e.g. with addr2line). >>> >>> >>> >>> Here's a much better dump of information. This time I went with no netfilter stuff loaded, very bare bones. Without those modules, the dump didn't scroll past the screen so I was able to get the rather important bit about KERNEL: ASSERTION (x->km.state == XFRM_STATE_DEAD) failed at net/xfrm/xfrm_state.c (193) (this is in __xfrm_state_destroy). So the state of my transform is set to dead for some reason, next question is why that would be. I still die in __xfrm4_state_lookup on the list_for_each_entry. KERNEL: ASSERTION (x->km.state == XFRM_STATE_DEAD) failed at net/xfrm/xfrm_state.c (193) Unable to handle kernel paging request at virtual address 39302035 printing eip: c02a7c8f *pde = 00000000 Oops: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010282 EIP is at __xfrm4_state_lookup+0x6f/0xa0 Call Trace: xfrm_state_lookup+0x4c/0x70 xfrm4_rcv_encap+0x9f/0x390 default_wake_function+0x2a/0x30 xfrm4_rcv+0x17/0x20 ip_local_deliver+0xe5/0x230 ip_rcv+0x31f/0x470 netif_recieve_skb+0x183/0x200 From krkumar@us.ibm.com Wed Nov 5 16:03:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 16:03:49 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA603925009587 for ; Wed, 5 Nov 2003 16:03:16 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA6033hn564492; Wed, 5 Nov 2003 19:03:03 -0500 Received: from DYN318430BLD.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA60320N201486; Wed, 5 Nov 2003 19:03:02 -0500 Date: Wed, 5 Nov 2003 16:00:49 -0800 (PST) From: Krishna Kumar X-X-Sender: krkumar@DYN318430BLD.beaverton.ibm.com To: davem@redhat.com cc: netdev@oss.sgi.com Subject: [PATCH] panic during unregister_netdevice() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1237 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Hi dave, While doing a test comprising of : insmod e100 ifup eth0 rmmod e100 on test9-bk9 bits, I got the following Oops : Nov 5 14:54:58 linux kernel: Unable to handle kernel paging request at virtual address 0260025d Nov 5 14:54:58 linux kernel: printing eip: Nov 5 14:54:58 linux kernel: c0318a5a Nov 5 14:54:58 linux kernel: *pde = 00000000 Nov 5 14:54:58 linux kernel: Oops: 0000 [#1] Nov 5 14:54:58 linux kernel: CPU: 0 Nov 5 14:54:58 linux kernel: EIP: 0060:[__rta_fill+90/160] Not tainted Nov 5 14:54:58 linux kernel: EIP: 0060:[] Not tainted Nov 5 14:54:58 linux kernel: EFLAGS: 00010282 Nov 5 14:54:58 linux kernel: EIP is at __rta_fill+0x5a/0xa0 Nov 5 14:54:58 linux kernel: eax: 00000008 ebx: 00000004 ecx: 00000001 edx: c94fe980 Nov 5 14:54:58 linux kernel: esi: 0260025d edi: c7e8a054 ebp: c1553e64 esp: c1553e48 Nov 5 14:54:58 linux kernel: ds: 007b es: 007b ss: 0068 Nov 5 14:54:58 linux kernel: Process events/0 (pid: 4, threadinfo=c1552000 task=c152c670) Nov 5 14:54:58 linux kernel: Stack: c1553e6c c011b36e c0433800 00000008 c7e8a050 ce77a000 00000000 c1553e98 Nov 5 14:54:58 linux kernel: c0318fee c94fe980 0000000a 00000004 0260025d c030a268 00000000 c7e8a000 Nov 5 14:54:58 linux kernel: 011b000e c94fe980 ce77a000 00000011 c1553ec8 c031943c c94fe980 ce77a000 Nov 5 14:54:58 linux kernel: Call Trace: Nov 5 14:54:58 linux kernel: [recalc_task_prio+126/384] recalc_task_prio+0x7e/0x180 Nov 5 14:54:58 linux kernel: [] recalc_task_prio+0x7e/0x180 Nov 5 14:54:58 linux kernel: [rtnetlink_fill_ifinfo+862/1264] rtnetlink_fill_ifinfo+0x35e/0x4f0 Nov 5 14:54:58 linux kernel: [] rtnetlink_fill_ifinfo+0x35e/0x4f0 Nov 5 14:54:58 linux kernel: [alloc_skb+72/240] alloc_skb+0x48/0xf0 Nov 5 14:54:58 linux kernel: [] alloc_skb+0x48/0xf0 Nov 5 14:54:58 linux kernel: [rtmsg_ifinfo+92/208] rtmsg_ifinfo+0x5c/0xd0 Nov 5 14:54:58 linux kernel: [] rtmsg_ifinfo+0x5c/0xd0 Nov 5 14:54:58 linux kernel: [rtnetlink_event+48/117] rtnetlink_event+0x30/0x75 Nov 5 14:54:58 linux kernel: [] rtnetlink_event+0x30/0x75 Nov 5 14:54:58 linux kernel: [notifier_call_chain+45/80] notifier_call_chain+0x2d/0x50 Nov 5 14:54:58 linux kernel: [] notifier_call_chain+0x2d/0x50 Nov 5 14:54:58 linux kernel: [netdev_wait_allrefs+242/320] netdev_wait_allrefs+0xf2/0x140 Nov 5 14:54:58 linux kernel: [] netdev_wait_allrefs+0xf2/0x140 Nov 5 14:54:58 linux kernel: [netdev_run_todo+347/608] netdev_run_todo+0x15b/0x260 Nov 5 14:54:58 linux kernel: [] netdev_run_todo+0x15b/0x260 Nov 5 14:54:58 linux kernel: [worker_thread+531/800] worker_thread+0x213/0x320 Nov 5 14:54:58 linux kernel: [] worker_thread+0x213/0x320 Nov 5 14:54:58 linux kernel: [linkwatch_event+0/48] linkwatch_event+0x0/0x30 Nov 5 14:54:58 linux kernel: [] linkwatch_event+0x0/0x30 Nov 5 14:54:58 linux kernel: [default_wake_function+0/48] default_wake_function+0x0/0x30 Nov 5 14:54:58 linux kernel: [] default_wake_function+0x0/0x30 Nov 5 14:54:58 linux kernel: [ret_from_fork+6/20] ret_from_fork+0x6/0x14 Nov 5 14:54:58 linux kernel: [] ret_from_fork+0x6/0x14 Nov 5 14:54:58 linux kernel: [default_wake_function+0/48] default_wake_function+0x0/0x30 Nov 5 14:54:58 linux kernel: [] default_wake_function+0x0/0x30 Nov 5 14:54:58 linux kernel: [worker_thread+0/800] worker_thread+0x0/0x320 Nov 5 14:54:58 linux kernel: [] worker_thread+0x0/0x320 Nov 5 14:54:58 linux kernel: [kernel_thread_helper+5/24] kernel_thread_helper+0x5/0x18 Nov 5 14:54:58 linux kernel: [] kernel_thread_helper+0x5/0x18 Nov 5 14:54:58 linux kernel: Nov 5 14:54:58 linux kernel: Code: f3 a5 f6 c3 02 74 02 66 a5 f6 c3 01 74 01 a4 8b 5d f4 8b 75 I think the problem is as follows (changed between 2.4 and 2.6). unregister_netdevice() drops the last reference to the device and waits for the ref counter for the dev to drop to zero. While it is OK for unregister_netdevice to call notifier_call_chain (since it does a dev_put at the end of the routine), netdev_wait_allrefs() cannot do the same until it gets it's own reference. The dev can disappear during this when the last reference gets dropped by the process holding it. Following patch should fix it. I will try to reproduce this with and without the patch to be certain. Thanks, - KK diff -ruN linux-2.6.0-test9-bk9/net/core/dev.c linux-2.6.0-test9-bk9.new/net/core/dev.c --- linux-2.6.0-test9-bk9/net/core/dev.c 2003-11-05 15:43:21.000000000 -0800 +++ linux-2.6.0-test9-bk9.new/net/core/dev.c 2003-11-05 15:43:50.000000000 -0800 @@ -2749,8 +2749,10 @@ rtnl_exlock(); /* Rebroadcast unregister notification */ + dev_hold(dev); notifier_call_chain(&netdev_chain, NETDEV_UNREGISTER, dev); + dev_put(dev); if (test_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state)) { From kumarkr@us.ibm.com Wed Nov 5 16:27:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 16:27:57 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA60RF25013256 for ; Wed, 5 Nov 2003 16:27:24 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA60R9cF351550; Wed, 5 Nov 2003 19:27:09 -0500 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA60R86s164102; Wed, 5 Nov 2003 17:27:09 -0700 Subject: Re: [PATCH] panic during unregister_netdevice() To: davem@redhat.com Cc: netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Krishna Kumar Date: Wed, 5 Nov 2003 16:26:46 -0800 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 11/05/2003 17:27:08 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-archive-position: 1238 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev About the patch below, I am still not clear about dev->reg_state (NETREG_UNREGISTERING) being used correctly, or how netdev_run_todo works correctly, so possibly the race may not be fixed. I am trying to reproduce this again. I will look some more into this. thanks, - KK |---------+-------------------------------> | | krkumar@us.ltcfwd.li| | | nux.ibm.com | | | Sent by: | | | netdev-bounce@oss.sg| | | i.com | | | | | | | | | 11/05/2003 04:00 PM | | | | |---------+-------------------------------> >-----------------------------------------------------------------------------------------------------------------| | | | To: davem@redhat.com | | cc: netdev@oss.sgi.com | | Subject: [PATCH] panic during unregister_netdevice() | | | >-----------------------------------------------------------------------------------------------------------------| Hi dave, While doing a test comprising of : insmod e100 ifup eth0 rmmod e100 on test9-bk9 bits, I got the following Oops : Nov 5 14:54:58 linux kernel: Unable to handle kernel paging request at virtual address 0260025d Nov 5 14:54:58 linux kernel: printing eip: Nov 5 14:54:58 linux kernel: c0318a5a Nov 5 14:54:58 linux kernel: *pde = 00000000 Nov 5 14:54:58 linux kernel: Oops: 0000 [#1] Nov 5 14:54:58 linux kernel: CPU: 0 Nov 5 14:54:58 linux kernel: EIP: 0060:[__rta_fill+90/160] Not tainted Nov 5 14:54:58 linux kernel: EIP: 0060:[] Not tainted Nov 5 14:54:58 linux kernel: EFLAGS: 00010282 Nov 5 14:54:58 linux kernel: EIP is at __rta_fill+0x5a/0xa0 Nov 5 14:54:58 linux kernel: eax: 00000008 ebx: 00000004 ecx: 00000001 edx: c94fe980 Nov 5 14:54:58 linux kernel: esi: 0260025d edi: c7e8a054 ebp: c1553e64 esp: c1553e48 Nov 5 14:54:58 linux kernel: ds: 007b es: 007b ss: 0068 Nov 5 14:54:58 linux kernel: Process events/0 (pid: 4, threadinfo=c1552000 task=c152c670) Nov 5 14:54:58 linux kernel: Stack: c1553e6c c011b36e c0433800 00000008 c7e8a050 ce77a000 00000000 c1553e98 Nov 5 14:54:58 linux kernel: c0318fee c94fe980 0000000a 00000004 0260025d c030a268 00000000 c7e8a000 Nov 5 14:54:58 linux kernel: 011b000e c94fe980 ce77a000 00000011 c1553ec8 c031943c c94fe980 ce77a000 Nov 5 14:54:58 linux kernel: Call Trace: Nov 5 14:54:58 linux kernel: [recalc_task_prio+126/384] recalc_task_prio+0x7e/0x180 Nov 5 14:54:58 linux kernel: [] recalc_task_prio+0x7e/0x180 Nov 5 14:54:58 linux kernel: [rtnetlink_fill_ifinfo+862/1264] rtnetlink_fill_ifinfo+0x35e/0x4f0 Nov 5 14:54:58 linux kernel: [] rtnetlink_fill_ifinfo+0x35e/0x4f0 Nov 5 14:54:58 linux kernel: [alloc_skb+72/240] alloc_skb+0x48/0xf0 Nov 5 14:54:58 linux kernel: [] alloc_skb+0x48/0xf0 Nov 5 14:54:58 linux kernel: [rtmsg_ifinfo+92/208] rtmsg_ifinfo+0x5c/0xd0 Nov 5 14:54:58 linux kernel: [] rtmsg_ifinfo+0x5c/0xd0 Nov 5 14:54:58 linux kernel: [rtnetlink_event+48/117] rtnetlink_event+0x30/0x75 Nov 5 14:54:58 linux kernel: [] rtnetlink_event+0x30/0x75 Nov 5 14:54:58 linux kernel: [notifier_call_chain+45/80] notifier_call_chain+0x2d/0x50 Nov 5 14:54:58 linux kernel: [] notifier_call_chain+0x2d/0x50 Nov 5 14:54:58 linux kernel: [netdev_wait_allrefs+242/320] netdev_wait_allrefs+0xf2/0x140 Nov 5 14:54:58 linux kernel: [] netdev_wait_allrefs+0xf2/0x140 Nov 5 14:54:58 linux kernel: [netdev_run_todo+347/608] netdev_run_todo+0x15b/0x260 Nov 5 14:54:58 linux kernel: [] netdev_run_todo+0x15b/0x260 Nov 5 14:54:58 linux kernel: [worker_thread+531/800] worker_thread+0x213/0x320 Nov 5 14:54:58 linux kernel: [] worker_thread+0x213/0x320 Nov 5 14:54:58 linux kernel: [linkwatch_event+0/48] linkwatch_event+0x0/0x30 Nov 5 14:54:58 linux kernel: [] linkwatch_event+0x0/0x30 Nov 5 14:54:58 linux kernel: [default_wake_function+0/48] default_wake_function+0x0/0x30 Nov 5 14:54:58 linux kernel: [] default_wake_function+0x0/0x30 Nov 5 14:54:58 linux kernel: [ret_from_fork+6/20] ret_from_fork+0x6/0x14 Nov 5 14:54:58 linux kernel: [] ret_from_fork+0x6/0x14 Nov 5 14:54:58 linux kernel: [default_wake_function+0/48] default_wake_function+0x0/0x30 Nov 5 14:54:58 linux kernel: [] default_wake_function+0x0/0x30 Nov 5 14:54:58 linux kernel: [worker_thread+0/800] worker_thread+0x0/0x320 Nov 5 14:54:58 linux kernel: [] worker_thread+0x0/0x320 Nov 5 14:54:58 linux kernel: [kernel_thread_helper+5/24] kernel_thread_helper+0x5/0x18 Nov 5 14:54:58 linux kernel: [] kernel_thread_helper+0x5/0x18 Nov 5 14:54:58 linux kernel: Nov 5 14:54:58 linux kernel: Code: f3 a5 f6 c3 02 74 02 66 a5 f6 c3 01 74 01 a4 8b 5d f4 8b 75 I think the problem is as follows (changed between 2.4 and 2.6). unregister_netdevice() drops the last reference to the device and waits for the ref counter for the dev to drop to zero. While it is OK for unregister_netdevice to call notifier_call_chain (since it does a dev_put at the end of the routine), netdev_wait_allrefs() cannot do the same until it gets it's own reference. The dev can disappear during this when the last reference gets dropped by the process holding it. Following patch should fix it. I will try to reproduce this with and without the patch to be certain. Thanks, - KK diff -ruN linux-2.6.0-test9-bk9/net/core/dev.c linux-2.6.0-test9-bk9.new/net/core/dev.c --- linux-2.6.0-test9-bk9/net/core/dev.c 2003-11-05 15:43:21.000000000 -0800 +++ linux-2.6.0-test9-bk9.new/net/core/dev.c 2003-11-05 15:43:50.000000000 -0800 @@ -2749,8 +2749,10 @@ rtnl_exlock(); /* Rebroadcast unregister notification */ + dev_hold(dev); notifier_call_chain(&netdev_chain, NETDEV_UNREGISTER, dev); + dev_put(dev); if (test_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state)) { From shemminger@osdl.org Wed Nov 5 16:30:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 16:31:10 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA60UH25013612 for ; Wed, 5 Nov 2003 16:30:37 -0800 Received: from dell_ss3.pdx.osdl.net (IDENT:2997@dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id hA60U4C02926; Wed, 5 Nov 2003 16:30:04 -0800 Date: Wed, 5 Nov 2003 16:30:25 -0800 From: Stephen Hemminger To: Krishna Kumar Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] panic during unregister_netdevice() Message-Id: <20031105163025.796cc462.shemminger@osdl.org> In-Reply-To: References: Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1239 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev > > diff -ruN linux-2.6.0-test9-bk9/net/core/dev.c linux-2.6.0-test9-bk9.new/net/core/dev.c > --- linux-2.6.0-test9-bk9/net/core/dev.c 2003-11-05 15:43:21.000000000 -0800 > +++ linux-2.6.0-test9-bk9.new/net/core/dev.c 2003-11-05 15:43:50.000000000 -0800 > @@ -2749,8 +2749,10 @@ > rtnl_exlock(); > > /* Rebroadcast unregister notification */ > + dev_hold(dev); > notifier_call_chain(&netdev_chain, > NETDEV_UNREGISTER, dev); > + dev_put(dev); > > if (test_bit(__LINK_STATE_LINKWATCH_PENDING, > &dev->state)) { > Hey, what if the dev refcount goes to zero before your dev_hold? Actually this repeated notifier looks like it wouldn't work anyway. Why would a protocol drop it's reference when notified a second time? I would argue even running the loop once means some protocol is busted. From davem@pizda.ninka.net Wed Nov 5 16:39:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 16:39:44 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA60d125014514 for ; Wed, 5 Nov 2003 16:39:02 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA05210; Wed, 5 Nov 2003 16:33:51 -0800 Date: Wed, 5 Nov 2003 16:33:50 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: krkumar@us.ibm.com, netdev@oss.sgi.com Subject: Re: [PATCH] panic during unregister_netdevice() Message-Id: <20031105163350.66bf2763.davem@redhat.com> In-Reply-To: <20031105163025.796cc462.shemminger@osdl.org> References: <20031105163025.796cc462.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1240 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 5 Nov 2003 16:30:25 -0800 Stephen Hemminger wrote: > Hey, what if the dev refcount goes to zero before your dev_hold? > Actually this repeated notifier looks like it wouldn't work anyway. > Why would a protocol drop it's reference when notified a second time? > > I would argue even running the loop once means some protocol is busted. If the loops runs once or twice that is not a bug, it is possible for processes to grab onto the device via rtnetlink queries and similar and we have to pause and potentially schedule to deal with that. The core problem is that we end up putting the device reference to zero a second time, and for that reason we should prevent it by holding onto a reference around the entire loop and wait for the refcount to drop to '1'. That would fix the bug wouldn't it? From kumarkr@us.ibm.com Wed Nov 5 16:42:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 16:43:29 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA60gt25015252 for ; Wed, 5 Nov 2003 16:42:56 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA60gikF358828; Wed, 5 Nov 2003 19:42:44 -0500 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA60gh6s160818; Wed, 5 Nov 2003 17:42:43 -0700 Subject: Re: [PATCH] panic during unregister_netdevice() To: Stephen Hemminger Cc: davem@redhat.com, krkumar@us.ibm.com, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Krishna Kumar Date: Wed, 5 Nov 2003 16:42:12 -0800 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 11/05/2003 17:42:43 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-archive-position: 1241 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev > Hey, what if the dev refcount goes to zero before your dev_hold? Actually, that is what I had written in my second mail. > I would argue even running the loop once means some protocol is busted. I have seen a message regarding ref count of 1, some delay and then the rmmod works fine. So it doesn't seem busted. - KK |---------+----------------------------> | | Stephen Hemminger| | | | | | Sent by: | | | netdev-bounce@oss| | | .sgi.com | | | | | | | | | 11/05/2003 04:30 | | | PM | | | | |---------+----------------------------> >-----------------------------------------------------------------------------------------------------------------| | | | To: krkumar@us.ltcfwd.linux.ibm.com | | cc: davem@redhat.com, netdev@oss.sgi.com | | Subject: Re: [PATCH] panic during unregister_netdevice() | | | >-----------------------------------------------------------------------------------------------------------------| > > diff -ruN linux-2.6.0-test9-bk9/net/core/dev.c linux-2.6.0-test9-bk9.new/net/core/dev.c > --- linux-2.6.0-test9-bk9/net/core/dev.c 2003-11-05 15:43:21.000000000 -0800 > +++ linux-2.6.0-test9-bk9.new/net/core/dev.c 2003-11-05 15:43:50.000000000 -0800 > @@ -2749,8 +2749,10 @@ > rtnl_exlock(); > > /* Rebroadcast unregister notification */ > + dev_hold(dev); > notifier_call_chain(&netdev_chain, > NETDEV_UNREGISTER, dev); > + dev_put(dev); > > if (test_bit(__LINK_STATE_LINKWATCH_PENDING, > &dev->state)) { > Hey, what if the dev refcount goes to zero before your dev_hold? Actually this repeated notifier looks like it wouldn't work anyway. Why would a protocol drop it's reference when notified a second time? I would argue even running the loop once means some protocol is busted. From shemminger@osdl.org Wed Nov 5 17:09:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 17:09:50 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA619925015853 for ; Wed, 5 Nov 2003 17:09:09 -0800 Received: from dell_ss3.pdx.osdl.net (IDENT:2997@dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id hA618tC10887; Wed, 5 Nov 2003 17:08:56 -0800 Date: Wed, 5 Nov 2003 17:09:15 -0800 From: Stephen Hemminger To: Krishna Kumar Cc: davem@redhat.com, krkumar@us.ibm.com, netdev@oss.sgi.com Subject: Re: [PATCH] panic during unregister_netdevice() Message-Id: <20031105170915.14793157.shemminger@osdl.org> In-Reply-To: References: Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1242 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Try this. Instead of dropping the last reference in unregister, it does it after all other references are gone (sort of like the old 2.4 code). diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Wed Nov 5 17:04:57 2003 +++ b/net/core/dev.c Wed Nov 5 17:04:57 2003 @@ -2743,7 +2743,7 @@ unsigned long rebroadcast_time, warning_time; rebroadcast_time = warning_time = jiffies; - while (atomic_read(&dev->refcnt) != 0) { + while (atomic_read(&dev->refcnt) > 1) { if (time_after(jiffies, rebroadcast_time + 1 * HZ)) { rtnl_shlock(); rtnl_exlock(); @@ -2838,6 +2838,7 @@ dev->reg_state = NETREG_UNREGISTERED; netdev_wait_allrefs(dev); + dev_put(dev); /* paranoia */ BUG_ON(atomic_read(&dev->refcnt)); @@ -2974,7 +2975,6 @@ /* Finish processing unregister after unlock */ net_set_todo(dev); - dev_put(dev); return 0; } From kumarkr@us.ibm.com Wed Nov 5 17:17:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 17:17:43 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA61H725016265 for ; Wed, 5 Nov 2003 17:17:08 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA61GtcF129032; Wed, 5 Nov 2003 20:16:55 -0500 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA61Gs6s164034; Wed, 5 Nov 2003 18:16:55 -0700 Subject: Re: [PATCH] panic during unregister_netdevice() To: "David S. Miller" Cc: krkumar@us.ibm.com, netdev@oss.sgi.com, Stephen Hemminger X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Krishna Kumar Date: Wed, 5 Nov 2003 17:16:10 -0800 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 11/05/2003 18:16:54 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-archive-position: 1243 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev > If the loops runs once or twice that is not a bug, it is possible for > processes to grab onto the device via rtnetlink queries and similar > and we have to pause and potentially schedule to deal with that. Yes. I guess rtnetlink_rcv() calls netdev_run_todo() to handle that case. > The core problem is that we end up putting the device reference to > zero a second time, and for that reason we should prevent it by > holding onto a reference around the entire loop and wait for the > refcount to drop to '1'. That was my original intention, but won't a driver that calls unregister_netdevice() followed by a free_netdev() still panic the system ? Since the netdev_run_todo() can run after this is done and derefernce the 'dev'. (Or is the refcount of the dev->kobject going to be > 1 and hence not freed ? This class/object code is new to me). Thanks, - KK From kumarkr@us.ibm.com Wed Nov 5 17:21:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 17:21:51 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA61LG25016623 for ; Wed, 5 Nov 2003 17:21:16 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA61L4kF135216; Wed, 5 Nov 2003 20:21:04 -0500 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA61L36s159532; Wed, 5 Nov 2003 18:21:03 -0700 Subject: Re: [PATCH] panic during unregister_netdevice() To: Stephen Hemminger Cc: davem@redhat.com, krkumar@us.ibm.com, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Krishna Kumar Date: Wed, 5 Nov 2003 17:20:06 -0800 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 11/05/2003 18:21:02 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-archive-position: 1244 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev So how will this guarantee that the dev is valid after the dev_put() long enough to do the BUG_ON() and dev->destructor code ? Won't the same panic happen ? Any idea how the dev gets freed up ? I was still in the old 2.4 kernel mode thinking that dev_put does it, but it seems to be done by using the class/object stuff in free_netdev(). Won't a driver doing a unregister followed by a free_netdev still panic the system if we reference the dev at a later stage (even with the put at this place) ? thanks, - KK |---------+----------------------------> | | Stephen Hemminger| | | | | | Sent by: | | | netdev-bounce@oss| | | .sgi.com | | | | | | | | | 11/05/2003 05:09 | | | PM | | | | |---------+----------------------------> >-----------------------------------------------------------------------------------------------------------------| | | | To: Krishna Kumar/Beaverton/IBM@IBMUS | | cc: davem@redhat.com, krkumar@us.ltcfwd.linux.ibm.com, netdev@oss.sgi.com | | Subject: Re: [PATCH] panic during unregister_netdevice() | | | >-----------------------------------------------------------------------------------------------------------------| Try this. Instead of dropping the last reference in unregister, it does it after all other references are gone (sort of like the old 2.4 code). diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Wed Nov 5 17:04:57 2003 +++ b/net/core/dev.c Wed Nov 5 17:04:57 2003 @@ -2743,7 +2743,7 @@ unsigned long rebroadcast_time, warning_time; rebroadcast_time = warning_time = jiffies; - while (atomic_read(&dev->refcnt) != 0) { + while (atomic_read(&dev->refcnt) > 1) { if (time_after(jiffies, rebroadcast_time + 1 * HZ)) { rtnl_shlock(); rtnl_exlock(); @@ -2838,6 +2838,7 @@ dev->reg_state = NETREG_UNREGISTERED; netdev_wait_allrefs(dev); + dev_put(dev); /* paranoia */ BUG_ON(atomic_read(&dev->refcnt)); @@ -2974,7 +2975,6 @@ /* Finish processing unregister after unlock */ net_set_todo(dev); - dev_put(dev); return 0; } From shemminger@osdl.org Wed Nov 5 17:33:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 17:34:04 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA61XO25017078 for ; Wed, 5 Nov 2003 17:33:25 -0800 Received: from dell_ss3.pdx.osdl.net (IDENT:2997@dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id hA61WpC14667; Wed, 5 Nov 2003 17:32:51 -0800 Date: Wed, 5 Nov 2003 17:33:11 -0800 From: Stephen Hemminger To: Krishna Kumar Cc: davem@redhat.com, krkumar@us.ibm.com, netdev@oss.sgi.com Subject: Re: [PATCH] panic during unregister_netdevice() Message-Id: <20031105173311.0b9f8bfc.shemminger@osdl.org> In-Reply-To: References: Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1245 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Wed, 5 Nov 2003 17:20:06 -0800 Krishna Kumar wrote: > > > > > So how will this guarantee that the dev is valid after the dev_put() long > enough to do the > BUG_ON() and dev->destructor code ? Won't the same panic happen ? > Because the code there should be able to depend on having the last reference. No other code should be able to find the dev to get a new reference to it, since it is no longer in the dev_list. Code that does dev_hold's without already having a reference is just not playing fair. > Any idea how the dev gets freed up ? I was still in the old 2.4 kernel mode > thinking that > dev_put does it, but it seems to be done by using the class/object stuff in > free_netdev(). > > Won't a driver doing a unregister followed by a free_netdev still panic the > system if we > reference the dev at a later stage (even with the put at this place) ? > > thanks, > > - KK > From kumarkr@us.ibm.com Wed Nov 5 17:43:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 17:43:45 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA61hA25017506 for ; Wed, 5 Nov 2003 17:43:10 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA61gwlQ312766; Wed, 5 Nov 2003 20:42:58 -0500 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA61gv6s156490; Wed, 5 Nov 2003 18:42:57 -0700 Subject: Re: [PATCH] panic during unregister_netdevice() To: Stephen Hemminger Cc: davem@redhat.com, krkumar@us.ibm.com, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Krishna Kumar Date: Wed, 5 Nov 2003 17:42:28 -0800 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 11/05/2003 18:42:57 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-archive-position: 1246 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev Nope, I still get the panic with the change you suggested. We need to understand this better though we seem to be on the right track. I will try to get the stack now (couldn't get this time since I was on the X display, my mouse still works but not the keyboard). Thanks, - KK |---------+----------------------------> | | Stephen Hemminger| | | | | | Sent by: | | | netdev-bounce@oss| | | .sgi.com | | | | | | | | | 11/05/2003 05:33 | | | PM | | | | |---------+----------------------------> >-----------------------------------------------------------------------------------------------------------------| | | | To: Krishna Kumar/Beaverton/IBM@IBMUS | | cc: davem@redhat.com, krkumar@us.ltcfwd.linux.ibm.com, netdev@oss.sgi.com | | Subject: Re: [PATCH] panic during unregister_netdevice() | | | >-----------------------------------------------------------------------------------------------------------------| On Wed, 5 Nov 2003 17:20:06 -0800 Krishna Kumar wrote: > > > > > So how will this guarantee that the dev is valid after the dev_put() long > enough to do the > BUG_ON() and dev->destructor code ? Won't the same panic happen ? > Because the code there should be able to depend on having the last reference. No other code should be able to find the dev to get a new reference to it, since it is no longer in the dev_list. Code that does dev_hold's without already having a reference is just not playing fair. > Any idea how the dev gets freed up ? I was still in the old 2.4 kernel mode > thinking that > dev_put does it, but it seems to be done by using the class/object stuff in > free_netdev(). > > Won't a driver doing a unregister followed by a free_netdev still panic the > system if we > reference the dev at a later stage (even with the put at this place) ? > > thanks, > > - KK > From hadi@cyberus.ca Wed Nov 5 19:29:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 19:30:15 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA63Td25019296 for ; Wed, 5 Nov 2003 19:29:40 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1AHaq1-0000tX-9f; Wed, 05 Nov 2003 22:29:37 -0500 Subject: Re: Announce: NetKeeper Firewall For Linux From: jamal Reply-To: hadi@cyberus.ca To: Emmanuel Fleury Cc: "David S. Miller" , netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, Mikkel Christiansen In-Reply-To: <1068046114.31636.92.camel@rade7.s.cs.auc.dk> References: <1067285612.552.9.camel@aphrodite.olympus.net> <20031028014223.129933be.davem@redhat.com> <1067335655.10628.7.camel@rade7.s.cs.auc.dk> <1068001237.1064.31.camel@jzny.localdomain> <1068046114.31636.92.camel@rade7.s.cs.auc.dk> Content-Type: text/plain; charset=ISO-8859-1 Organization: jamalopolis Message-Id: <1068089345.1020.17.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Nov 2003 22:29:06 -0500 Content-Transfer-Encoding: 8bit X-archive-position: 1247 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Hi, On Wed, 2003-11-05 at 10:28, Emmanuel Fleury wrote: > Hi, > > On Wed, 2003-11-05 at 04:00, jamal wrote: > > > > You seem to be attempting to replicate that functionality actually;-> > > (as opposed to using it). Therefore you are going to miss a lot of > > good things. What was posted already is just the beggining. > > I'm not sure it is the case (but I might have missed the point). > Yes, i think you missed my point ;-> You guys are doing a great job at coming up with some good packet classification algorithm(s). I wanna encourage you to continue doing that. OTOH, I have spent a lot of time thinking and coming up with a good architecture for the action part (that follows classification). So it will be a shame if you miss that because you happened to see one good thing in the old code. Putting the two together will result in some good things. You trying to redo what i am doing will mean you are always a few steps behind[1]. Now if you can do it better than what i have, then you can convert me too - thats the way opensource works. > Anyway, reading some new code can give us nice ideas. > We would be pleased to see what you've already achieved. > Lets work together instead of you trying to get nice ideas from my new code. This way you benefit from any evolution i have; and i have lots coming down. You must switch to making your code tc filter capable to do this. > > Why do you have a limit to 8 actions? > > This limit is totally artificial. > > Basically, the story is that we had a union in a struct and we filled up > the memory space with these actions so that no memory was left behind. > We decided (on arbitrary basis) that nobody would attach more than 8 > different actions to a precise packet. We also though that having 256 > different actions would be enough. > Probably true; but no point in making the limits when you dont have to. > In fact, these two limits (8 and 256) are totally artificial and > have been introduced in our prototype just because it was "convenient". > We can extend the list of actions by using a chained list and code the > actions on a bigger variable than a byte. > I dont understand why you even have this byte to encode an action. Look at my code. > > BTW, since you compile your filters, how fast are you at adding rules? > > So, here, you are hitting the sensitive spot ! > > In fact, we are totally ignorant of what are the requirements on these > dynamic updates in networking. So any discussion about this is extremely > valuable for us. > Anything that requires "connection setup" to dynamically add rules is a candidate. Think Voip SIP Proxy server for example which will insert rules; think any authentication schemes that are needed before installing rules, think tcp-splicing etc. > For your question, the theory (and the practice) is telling us that the > time to add a new rule to an existing ruleset depend essentially of the > complexity of the already existing ruleset. > I think thats a design issue. For example while u32 classifier may not process as fast as you (lookups would take longer relatively ) - its insertion time is independent of the complexity of the rules. Lakshman (sp?) had a good paper on the tradeoffs between memory space used, lookup times and insertion times (there was another variable) and i think he may have proved you cant have all of them work well at the same time. > Don't miss my point, the number of rules which compose the ruleset is > not the only parameter. Because, as your are going through an > optimization a ruleset with a lot of trivial rules is simplified and > will be trivial at the end. > > Therefore, it essentially depend on the ruleset to which you are adding > your new rule. > > But, we still have to work on this part. The way we have coded the > compiler is very simple and we have already some ideas on how to > optimize it. > > Actually, a good thing for us would be to know what are your expectation > in matter of adding a new rule. What is "acceptable" and what is "not". > > And, now, some tables with numbers: > > +--+--+--+--+--+ > | #rules | time(s) | nodes | edges | size(KB) | > +--+--+--+--+--+ > | 10 | 0.01 | 28 | 102 | 1.584 | > | 25 | 0.03 | 77 | 279 | 4.296 | > | 50 | 0.11 | 128 | 481 | 7.332 | > | 100 | 0.44 | 232 | 891 | 13.500 | > | 250 | 3.44 | 542 | 2109 | 31.836 | > | 500 | 19.14 | 998 | 3952 | 59.424 | > | 1,000 | 37.72 | 1884 | 7544 | 113.160 | > | 2,500 | 102.1 | 4289 | 17493 | 261.408 | > | 5,000 | 237.0 | 7678 | 31880 | 474.720 | > | 10,000 | 571.4 | 13420 | 57417 | 850.068 | > | 25,000 | 1832.0 | 24657 |116673 | 1695.984 | > | 50,000 | 5221.0 | 37416 |198754 | 2834.064 | > +--+--+--+--+--+ > So if you add rule #50000 while there are already 49999 existing it will take over an hour to install in the worst case, did i understand this correctly? > The rulesets considered here are totally artificially generated and are > matching our worst case in term of computing time. > > Of course your question was about taking one of this big filters and > then add one tiny winny rule to it. So, I guess the time to do so would > be at most 1s (in the very worst case, I would say). > Ok, so i didnt understand your table above then. 1s is very bad; actually i shouldnt say that since i dont have numbers infront of me of what is considered good. I will look this up > > What about dynamic in kernel rules (such as those that may be created > > by contracking) - do you have to cross to user space to compile them? > > We have some ideas on how to handle it. But for now, the scheme is > totally static. I would say that we are keeping this area of research > (stateful inspection) for later. :) > Which is fine. I would say for something like firewalling you have a desirable feature of very optimized lookups. > > - Is there any reason you move the commit decision to the kernel? > > Could this not have been done in user space? > > Yes, definitely. > > When coding in the kernel, we are coding with the idea that: > « The kernel should defend itself against user-space. » > > So, when the user say: "Commit". > > The kernel will first check the decision diagram for safety (no NULL > pointers, out of range variables, no loops, etc) and depending of the > tests, will take the decision to commit or not. > > Actually, I think I read some stuff about it on the Netfilter-devel > mailing-list. As far as I remember, there was a similar problem in > netfilter as the safety of the whole thing is never really tested in > depth. Therefore you can end-up with some loops or inconsistancy > (WARNING: I'm not sure about it!). > That sounds more like still a user space problem ;-> I saw in your paper briefly that you have infact a checker for something like this. That checker should run outside the kernel in my opinion. The value in putting the commit in the kernel maybe for say making sure you get the memory allocation you want etc before installing. But even this is not a strong arguement. > > I have doubts how fast you can install rules - which is a fundamental > > measure of good filters. > > The fact is that theory is saying that optimizing is a complex problem > (but it still has a polynomial time complexity ). But, we can for sure > improve A LOT our current tools. The problem for us is that we do not > know against what we are fighting ! We really need some hints on how > fast should be this operation (just to see if it is possible or not in > our scheme). > So i would suggest that you look at the Lakshman paper for starters. In my view the most important issues in priority order are: lookup speed regardless of table size, insert/delete rate regardless of table size, Capacity (should be able to go to the hundreds of thousands of flows), memory use for storage purposes - although i dont really care very much about these since memory is cheap these days. > PS: I would like also to say here that we got a really great feed back > from the nf-hipac team. So, thank a lot to Michael Bellion and Thomas > Heinz. > I am sorry i confused you with them;-> I suppose you are both from .dk. cheers, jamal [1]I briefly looked at your paper and it seems the only action you had initially was DENY or ACCEPT. Looking at your code you now have an action dispatcher that seems to be exactly like the old one i have (you havent implemented code around it but you have the hooks in place). This is why i made the comment. From greearb@candelatech.com Wed Nov 5 20:24:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 20:25:21 -0800 (PST) Received: from grok.yi.org (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA64Om25022880 for ; Wed, 5 Nov 2003 20:24:49 -0800 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id hA64OhQN025015 for ; Wed, 5 Nov 2003 20:24:43 -0800 Message-ID: <3FA9CD0B.8000707@candelatech.com> Date: Wed, 05 Nov 2003 20:24:43 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: [PATCH] 802.1q vlan updates Content-Type: multipart/mixed; boundary="------------080500030205060300080101" X-archive-position: 1248 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------080500030205060300080101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Here is a patch that is a cleaned up version of something I sent a while back. This adds the ability to query a device to see if it is a vlan device by asking for the vlan's parent device. One can deduce that a querried interface is not a VLAN by looking at the IOCTL error code. Patch is against 2.4.22-pre9, compile tested and extracted from a run-time tested patch. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com --------------080500030205060300080101 Content-Type: text/plain; name="vlan_2.4.22.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vlan_2.4.22.patch" --- linux-2.4.22/net/8021q/vlan_dev.c 2003-11-05 19:54:38.000000000 -0800 +++ linux-2.4.22.vlan/net/8021q/vlan_dev.c 2003-11-05 19:41:20.000000000 -0800 @@ -1,4 +1,4 @@ -/* +/* -*- linux-c -*- * INET 802.1Q VLAN * Ethernet-type device handling. * @@ -636,6 +636,60 @@ return -EINVAL; } + +int vlan_dev_get_realdev_name(const char *dev_name, char* result) +{ + struct net_device *dev = dev_get_by_name(dev_name); + int rv = 0; + + if (dev) { + if (dev->priv_flags & IFF_802_1Q_VLAN) { + strncpy(result, VLAN_DEV_INFO(dev)->real_dev->name, 23); + dev_put(dev); + rv = 0; + } else { + /*printk(KERN_ERR + "%s: %s is not a vlan device, priv_flags: %hX.\n", + __FUNCTION__, dev->name, dev->priv_flags);*/ + dev_put(dev); + rv = -EINVAL; + } + } else { + /* printk(KERN_ERR "%s: Could not find device: %s\n", + __FUNCTION__, dev_name); */ + rv = -ENODEV; + } + + return rv; +} + +int vlan_dev_get_vid(const char *dev_name, unsigned short* result) +{ + struct net_device *dev = dev_get_by_name(dev_name); + int rv = 0; + + if (dev) { + if (dev->priv_flags & IFF_802_1Q_VLAN) { + *result = VLAN_DEV_INFO(dev)->vlan_id; + dev_put(dev); + rv = 0; + } else { + /*printk(KERN_ERR + "%s: %s is not a vlan device, priv_flags: %hX.\n", + __FUNCTION__, dev->name, dev->priv_flags);*/ + dev_put(dev); + rv = -EINVAL; + } + } else { + /* printk(KERN_ERR "%s: Could not find device: %s\n", + __FUNCTION__, dev_name);*/ + rv = -ENODEV; + } + + return rv; +} + + int vlan_dev_set_mac_address(struct net_device *dev, void *addr_struct_p) { struct sockaddr *addr = (struct sockaddr *)(addr_struct_p); --- linux-2.4.22/net/8021q/vlan.c 2003-11-05 19:54:38.000000000 -0800 +++ linux-2.4.22.vlan/net/8021q/vlan.c 2003-11-05 19:46:04.000000000 -0800 @@ -1,4 +1,4 @@ -/* +/* -*- linux-c -*- * INET 802.1Q VLAN * Ethernet-type device handling. * @@ -657,15 +657,9 @@ int vlan_ioctl_handler(unsigned long arg) { int err = 0; + unsigned short vid = 0; struct vlan_ioctl_args args; - /* everything here needs root permissions, except aguably the - * hack ioctls for sending packets. However, I know _I_ don't - * want users running that on my network! --BLG - */ - if (!capable(CAP_NET_ADMIN)) - return -EPERM; - if (copy_from_user(&args, (void*)arg, sizeof(struct vlan_ioctl_args))) return -EFAULT; @@ -680,24 +674,33 @@ switch (args.cmd) { case SET_VLAN_INGRESS_PRIORITY_CMD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + err = vlan_dev_set_ingress_priority(args.device1, args.u.skb_priority, args.vlan_qos); break; case SET_VLAN_EGRESS_PRIORITY_CMD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; err = vlan_dev_set_egress_priority(args.device1, args.u.skb_priority, args.vlan_qos); break; case SET_VLAN_FLAG_CMD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; err = vlan_dev_set_vlan_flag(args.device1, args.u.flag, args.vlan_qos); break; case SET_VLAN_NAME_TYPE_CMD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; if ((args.u.name_type >= 0) && (args.u.name_type < VLAN_NAME_TYPE_HIGHEST)) { vlan_name_type = args.u.name_type; @@ -707,17 +710,9 @@ } break; - /* TODO: Figure out how to pass info back... - case GET_VLAN_INGRESS_PRIORITY_IOCTL: - err = vlan_dev_get_ingress_priority(args); - break; - - case GET_VLAN_EGRESS_PRIORITY_IOCTL: - err = vlan_dev_get_egress_priority(args); - break; - */ - case ADD_VLAN_CMD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; /* we have been given the name of the Ethernet Device we want to * talk to: args.dev1 We also have the * VLAN ID: args.u.VID @@ -730,12 +725,53 @@ break; case DEL_VLAN_CMD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; /* Here, the args.dev1 is the actual VLAN we want * to get rid of. */ err = unregister_vlan_device(args.device1); break; + case GET_VLAN_INGRESS_PRIORITY_CMD: + /* TODO: Implement + err = vlan_dev_get_ingress_priority(args); + if (copy_to_user((void*)arg, &args, + sizeof(struct vlan_ioctl_args))) { + err = -EFAULT; + } + */ + err = -EINVAL; + break; + + case GET_VLAN_EGRESS_PRIORITY_CMD: + /* TODO: Implement + err = vlan_dev_get_egress_priority(args.device1, &(args.args); + if (copy_to_user((void*)arg, &args, + sizeof(struct vlan_ioctl_args))) { + err = -EFAULT; + } + */ + err = -EINVAL; + break; + + case GET_VLAN_REALDEV_NAME_CMD: + err = vlan_dev_get_realdev_name(args.device1, args.u.device2); + if (copy_to_user((void*)arg, &args, + sizeof(struct vlan_ioctl_args))) { + err = -EFAULT; + } + break; + + case GET_VLAN_VID_CMD: + err = vlan_dev_get_vid(args.device1, &vid); + args.u.VID = vid; + if (copy_to_user((void*)arg, &args, + sizeof(struct vlan_ioctl_args))) { + err = -EFAULT; + } + break; + default: /* pass on to underlying device instead?? */ printk(VLAN_DBG "%s: Unknown VLAN CMD: %x \n", --- linux-2.4.22/include/linux/if_vlan.h 2003-08-25 04:44:44.000000000 -0700 +++ linux-2.4.22.vlan/include/linux/if_vlan.h 2003-11-05 19:47:37.000000000 -0800 @@ -213,7 +213,9 @@ GET_VLAN_INGRESS_PRIORITY_CMD, GET_VLAN_EGRESS_PRIORITY_CMD, SET_VLAN_NAME_TYPE_CMD, - SET_VLAN_FLAG_CMD + SET_VLAN_FLAG_CMD, + GET_VLAN_REALDEV_NAME_CMD, /* If this works, you know it's a VLAN device, btw */ + GET_VLAN_VID_CMD /* Get the VID of this VLAN (specified by name) */ }; enum vlan_name_types { --------------080500030205060300080101-- From schuster.sven@gmx.de Wed Nov 5 23:31:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Nov 2003 23:32:23 -0800 (PST) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA67Vm25025121 for ; Wed, 5 Nov 2003 23:31:49 -0800 Received: (qmail 27078 invoked by uid 65534); 6 Nov 2003 07:31:42 -0000 Received: from unknown (EHLO gmx.de) (213.172.101.181) by mail.gmx.net (mp003) with SMTP; 06 Nov 2003 08:31:42 +0100 X-Authenticated: #2425915 Message-ID: <3FA9F8D5.9020601@gmx.de> Date: Thu, 06 Nov 2003 08:31:33 +0100 From: Sven Schuster User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: de-de, en, en-us MIME-Version: 1.0 To: linux-net@vger.kernel.org CC: netdev Subject: Linux <---> Unixware slow networking with e100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1249 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: schuster.sven@gmx.de Precedence: bulk X-list: netdev Hello everybody, we have a little problem here with networking between linux (redhat AS 2.1 2.4.9-e.27smp) and unixware 7.1.1 . The network card is a Intel 82557 Ethernet Pro 100 (lspci output) on a 100 mbit network. When doing data transfers between two linux machines, everything works fine, we have transfer rates of about 10 MB/s. But when _receiving_ data from one of the unixware machines, we just get a few kB/s, max. about 100 kB/s. When _sending_ data to a unixware machine, the transfer rate is fine too. Are there any known issues between linux and unixware (except the SCO thing ;-) ) ?? At first we used the eepro100 driver, but this gave us poor performance on receive with every other machine, whether it was unixware or linux. Another thing on that machine is, that there's a Intel 82544GC copper gigabit card in it. When using this one with the e1000 driver, it also gave us bad performance on receive (also just around max. 100 kB/s). Maxbe there are some options for module loading for the e1000 driver?? Thanks in advance for any tips!!! Sven From kuznet@ms2.inr.ac.ru Thu Nov 6 01:32:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Nov 2003 01:33:08 -0800 (PST) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [193.233.7.111]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA69W925030581 for ; Thu, 6 Nov 2003 01:32:29 -0800 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id MAA14771; Thu, 6 Nov 2003 12:31:28 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200311060931.MAA14771@yakov.inr.ac.ru> Subject: Re: Fw: issues with SO_PRIORITY and IP_TOS To: cfriesen@nortelnetworks.com (Chris Friesen) Date: Thu, 6 Nov 2003 12:31:28 +0300 (MSK) Cc: davem@redhat.com (David S. Miller), jmorris@redhat.com, hadi@znyx.com, netdev@oss.sgi.com In-Reply-To: <3FA7DBB5.1090500@nortelnetworks.com> from "Chris Friesen" at Nov 04, 2003 12:02:45 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1250 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > If that were the case, I'd be happy. However, when you set the TOS bits > (which really sets the whole 8-bit field, rather than just the 4 TOS > bits), It was not our choice. :-) > the kernel also sets the socket priority but only uses the TOS > bits to do so. Look at straces of your telnet, ftp and ssh. You will understand why it is made and why it would be better not to change this. It affects local queuing in right way in default situation. > If we're going to set the whole 8-bit field, wouldn't it > make sense to use the priority bits to set the priority? There are no "priority" bits in this field. Priority is defined by outgoing device. > If root wants to send out a packet with particular DSCP settings, > doesn't it make sense to make that option available? It's a field in > the IP packet header, we should be able to set it with an IP option. IP_TOS. :-) I feel there is some misunderstanding about sk->priority thing. It is the lowest significance hint about priority, when no other classification is supplied. Read: when the node is dumb and is not aware about any such things. I would agree with you if this field had opposite priority: i.e. overrided all the system-wide settings. It does not. What's about VLAN thing, this approach enforces you to use DSCP directly and never use skb->priority (well, to be more exact, to use it when you have no another hints available: in this case our skb->priority is _right_ hint) Alexey From fleury@cs.auc.dk Thu Nov 6 02:27:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Nov 2003 02:28:02 -0800 (PST) Received: from mailhost.cs.auc.dk (root@mailhost.cs.auc.dk [130.225.194.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6ARP25031431 for ; Thu, 6 Nov 2003 02:27:26 -0800 Received: from rade7.s.cs.auc.dk (fleury@rade7.s.cs.auc.dk [192.168.194.153]) by mailhost.cs.auc.dk (8.12.10/8.12.10) with ESMTP id hA6AR2lN011841; Thu, 6 Nov 2003 11:27:03 +0100 (MET) Subject: Re: Announce: NetKeeper Firewall For Linux From: Emmanuel Fleury To: hadi@cyberus.ca Cc: "David S. Miller" , netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, Mikkel Christiansen In-Reply-To: <1068089345.1020.17.camel@jzny.localdomain> References: <1067285612.552.9.camel@aphrodite.olympus.net> <20031028014223.129933be.davem@redhat.com> <1067335655.10628.7.camel@rade7.s.cs.auc.dk> <1068001237.1064.31.camel@jzny.localdomain> <1068046114.31636.92.camel@rade7.s.cs.auc.dk> <1068089345.1020.17.camel@jzny.localdomain> Content-Type: text/plain; charset=iso-8859-15 Organization: Aalborg University -- Computer Science Dept. Message-Id: <1068114376.1532.115.camel@rade7.s.cs.auc.dk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 06 Nov 2003 11:26:16 +0100 X-Scanned-By: MIMEDefang 2.14 X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.cs.auc.dk id hA6AR2lN011841 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hA6ARP25031431 X-archive-position: 1251 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fleury@cs.auc.dk Precedence: bulk X-list: netdev Hi, On Thu, 2003-11-06 at 04:29, jamal wrote: > > Yes, i think you missed my point ;-> Oops ! :) > You guys are doing a great job at coming up with some good packet > classification algorithm(s). I wanna encourage you to continue doing > that. > OTOH, I have spent a lot of time thinking and coming up with a good > architecture for the action part (that follows classification). So it > will be a shame if you miss that because you happened to see one > good thing in the old code. > Putting the two together will result in some good things. You trying to > redo what i am doing will mean you are always a few steps behind[1]. Now > if you can do it better than what i have, then you can convert me > too - thats the way opensource works. Ok, actually we were so focused on the classification scheme that we didn't really try to do something nice for the actions... In a matter of facts, we have only one action (log) and it is not even implemented. So, we will definitely look at your code to avoid us to have to think about this part (and avoid to have to recode the actions). > Anything that requires "connection setup" to dynamically add rules is a > candidate. Think Voip SIP Proxy server for example which will insert > rules; think any authentication schemes that are needed before > installing rules, think tcp-splicing etc. Ok, but you are speaking about non permanent rules (aka dynamic rules). The idea we have to handle stateful inspection is to have the core filter (totally static) plus some "state" nodes placed inside the IDD which are calling a function to evaluate the "state" of the packet (based on some informations given by the packet header and a database of the open connections). When reaching the terminals, one of the action can be to change the state of the connection. I guess that what you describe can be handled by such mechanism (better than changing the ruleset each time). As it is handled outside of the IDD, this take only the time of the look-up in the database and the time to modify the database (when necessary). But, I over simplified things here, this scheme is far from being ready at this point. We should investigate it more in depth (we need more time!!!). > I think thats a design issue. For example while u32 classifier may not > process as fast as you (lookups would take longer relatively ) - its > insertion time is independent of the complexity of the rules. > Lakshman (sp?) had a good paper on the tradeoffs between memory space > used, lookup times and insertion times (there was another variable) and > i think he may have proved you cant have all of them work well at the > same time. Ok. Could you give more details about the references of this paper from Lakshman ? > So if you add rule #50000 while there are already 49999 existing > it will take over an hour to install in the worst case, did i understand > this correctly? Yes (I messed up things in the following paragraph), you are totally right here. I totally forgot that you have to deal with rule-overlapping which is actually making things incredibly sequential). > > Of course your question was about taking one of this big filters and > > then add one tiny winy rule to it. So, I guess the time to do so would > > be at most 1s (in the very worst case, I would say). I am wrong here, terribly wrong. The thing is that is you add a rule at the end of your filter, you will not have to rebuild it, but inserting a rule randomly in the list is... bad. For now, we don't have any good algorithm to insert a rule, so we just rebuild the whole thing. > > When coding in the kernel, we are coding with the idea that: > > « The kernel should defend itself against user-space. » > > > > So, when the user say: "Commit". > > > > The kernel will first check the decision diagram for safety (no NULL > > pointers, out of range variables, no loops, etc) and depending of the > > tests, will take the decision to commit or not. > > That sounds more like still a user space problem ;-> No. Users shouldn't be able to break the kernel just by misconfiguring it. > I saw in your paper briefly that you have infact a checker for something > like this. If you are speaking about the "network access verifier", it is something totally different. But, I might have misunderstood you. > In my view the most important issues in priority order are: > lookup speed regardless of table size, insert/delete rate regardless of > table size, Capacity (should be able to go to the hundreds of thousands > of flows), memory use for storage purposes - although i dont really care > very much about these since memory is cheap these days. Ok, I think we have to work on the insert/delete part. I know for a fact that insert/delete inside the IDD is not an option (as the complexity of this operation is too high), so we will look at some other way to handle it. > > PS: I would like also to say here that we got a really great feed back > > from the nf-hipac team. So, thank a lot to Michael Bellion and Thomas > > Heinz. > > > > I am sorry i confused you with them;-> I suppose you are both from .dk. No, Michael and Thomas are from Germany. Mikkel Christiansen is from Denmark and I'm from France (working in Denmark currently). > [1]I briefly looked at your paper and it seems the only action you had > initially was DENY or ACCEPT. We can extend this without any problem. > Looking at your code you now have an action dispatcher that seems > to be exactly like the old one i have (you havent implemented code > around it but you have the hooks in place). This is why i made the > comment. Actually, as I said, we were just no so concerned about the handling of the actions, so we just did it in the most natural way (for us). It is a good sign that we are meeting your very first implementation. Regards -- Emmanuel Fleury Computer Science Department, | Office: B1-201 Aalborg University, | Phone: +45 96 35 72 23 Fredriks Bajersvej 7E, | Fax: +45 98 15 98 89 9220 Aalborg East, Denmark | Email: fleury@cs.auc.dk From sasha@mail.oktet.ru Thu Nov 6 03:56:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Nov 2003 03:56:54 -0800 (PST) Received: from mail.oktet.ru (mail.oktet.ru [193.125.193.3]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6Bu325001498 for ; Thu, 6 Nov 2003 03:56:17 -0800 Received: from mail.oktet.ru (localhost.localdomain [127.0.0.1]) by mail.oktet.ru (8.12.9/8.12.9) with ESMTP id hA6BtlUL021102; Thu, 6 Nov 2003 14:55:47 +0300 Received: (from sasha@localhost) by mail.oktet.ru (8.12.9/8.12.9/Submit) id hA6Btdmi021101; Thu, 6 Nov 2003 14:55:39 +0300 Date: Thu, 6 Nov 2003 14:55:38 +0300 From: "Alexandra N. Kossovsky" To: Francois Romieu Cc: linux-kernel@vger.kernel.org, ShuChen , netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: r8169 with big-endian (patch) Message-ID: <20031106145538.A21034@oktet.ru> References: <20031105104625.D26209@oktet.ru> <20031105193400.A12375@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20031105193400.A12375@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Wed, Nov 05, 2003 at 07:34:00PM +0100 X-archive-position: 1252 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sasha@oktet.ru Precedence: bulk X-list: netdev --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello. Here is next version of the patch, thanks to Francois Romieu. Best regards, Alexandra. -- Alexandra N. Kossovsky OKTET Ltd. http://www.oktet.ru/ 1 Ulianovskaya st., Petergof, St.Petersburg, 198904 Russia Phones: +7(812)428-43-84(work) +7(812)184-52-58(home) +7(812)956-42-86(mobile) mailto:sasha@oktet.ru --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="r8169.diff" --- drivers/net/r8169.c.orig 2003-11-06 14:53:18.000000000 +0300 +++ drivers/net/r8169.c 2003-11-06 14:54:17.000000000 +0300 @@ -33,6 +33,11 @@ - Copy mc_filter setup code from 8139cp (includes an optimization, and avoids set_bit use) +VERSION 1.2.1 2003/11/04 + (C) OKTET Ltd. (www.oktet.ru) + Author Alexandra N. Kossovsky + - Replace bus_to_virt/virt_to_bus by pci_alloc_consistent. + - Insert cpu_to_le/le_to_cpu where it is necessary. */ #include @@ -45,7 +50,7 @@ #include -#define RTL8169_VERSION "1.2" +#define RTL8169_VERSION "1.2.1" #define MODULENAME "r8169" #define RTL8169_DRIVER_NAME MODULENAME " Gigabit Ethernet driver " RTL8169_VERSION #define PFX MODULENAME ": " @@ -165,12 +170,6 @@ RxErr = 0x02, RxOK = 0x01, - /*RxStatusDesc */ - RxRES = 0x00200000, - RxCRC = 0x00080000, - RxRUNT = 0x00100000, - RxRWT = 0x00400000, - /*ChipCmdBits */ CmdReset = 0x10, CmdRxEnb = 0x08, @@ -251,10 +250,16 @@ "RTL-8169", 0x00, 0xff7e1880,},}; enum _DescStatusBit { - OWNbit = 0x80000000, - EORbit = 0x40000000, - FSbit = 0x20000000, - LSbit = 0x10000000, + OWNbit = __constant_cpu_to_le32(0x80000000), + EORbit = __constant_cpu_to_le32(0x40000000), + FSbit = __constant_cpu_to_le32(0x20000000), + LSbit = __constant_cpu_to_le32(0x10000000), + + /*RxStatusDesc */ + RxRES = __constant_cpu_to_le32(0x00200000), + RxCRC = __constant_cpu_to_le32(0x00080000), + RxRUNT = __constant_cpu_to_le32(0x00100000), + RxRWT = __constant_cpu_to_le32(0x00400000), }; struct TxDesc { @@ -280,17 +285,20 @@ unsigned long cur_rx; /* Index into the Rx descriptor buffer of next Rx pkt. */ unsigned long cur_tx; /* Index into the Tx descriptor buffer of next Rx pkt. */ unsigned long dirty_tx; - unsigned char *TxDescArrays; /* Index of Tx Descriptor buffer */ - unsigned char *RxDescArrays; /* Index of Rx Descriptor buffer */ struct TxDesc *TxDescArray; /* Index of 256-alignment Tx Descriptor buffer */ struct RxDesc *RxDescArray; /* Index of 256-alignment Rx Descriptor buffer */ + dma_addr_t TxDescDmaAddr; /* DMA address of TxDescArray */ + dma_addr_t RxDescDmaAddr; /* DMA address of RxDescArray */ unsigned char *RxBufferRings; /* Index of Rx Buffer */ unsigned char *RxBufferRing[NUM_RX_DESC]; /* Index of Rx Buffer array */ + dma_addr_t RxBufferDmas; /* DMA address of RxBufferRings */ + dma_addr_t RxBufferDma[NUM_RX_DESC]; /* DMA addresses of RxBufferRing */ struct sk_buff *Tx_skbuff[NUM_TX_DESC]; /* Index of Transmit data buffer */ }; MODULE_AUTHOR("Realtek"); MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver"); +MODULE_LICENSE("GPL"); MODULE_PARM(media, "1-" __MODULE_STRING(MAX_UNITS) "i"); static int rtl8169_open(struct net_device *dev); @@ -654,8 +662,6 @@ { struct rtl8169_private *tp = dev->priv; int retval; - u8 diff; - u32 TxPhyAddr, RxPhyAddr; retval = request_irq(dev->irq, rtl8169_interrupt, SA_SHIRQ, dev->name, dev); @@ -663,36 +669,37 @@ return retval; } - tp->TxDescArrays = - kmalloc(NUM_TX_DESC * sizeof (struct TxDesc) + 256, GFP_KERNEL); - // Tx Desscriptor needs 256 bytes alignment; - TxPhyAddr = virt_to_bus(tp->TxDescArrays); - diff = 256 - (TxPhyAddr - ((TxPhyAddr >> 8) << 8)); - TxPhyAddr += diff; - tp->TxDescArray = (struct TxDesc *) (tp->TxDescArrays + diff); - - tp->RxDescArrays = - kmalloc(NUM_RX_DESC * sizeof (struct RxDesc) + 256, GFP_KERNEL); - // Rx Desscriptor needs 256 bytes alignment; - RxPhyAddr = virt_to_bus(tp->RxDescArrays); - diff = 256 - (RxPhyAddr - ((RxPhyAddr >> 8) << 8)); - RxPhyAddr += diff; - tp->RxDescArray = (struct RxDesc *) (tp->RxDescArrays + diff); + tp->TxDescArray = (struct TxDesc *) + pci_alloc_consistent(tp->pci_dev, + NUM_TX_DESC * sizeof (struct TxDesc) + 256, + &tp->TxDescDmaAddr); + + tp->RxDescArray = (struct RxDesc *) + pci_alloc_consistent(tp->pci_dev, + NUM_RX_DESC * sizeof (struct RxDesc) + 256, + &tp->RxDescDmaAddr); - if (tp->TxDescArrays == NULL || tp->RxDescArrays == NULL) { + if (tp->TxDescArray == NULL || tp->RxDescArray == NULL) { printk(KERN_INFO "Allocate RxDescArray or TxDescArray failed\n"); free_irq(dev->irq, dev); - if (tp->TxDescArrays) - kfree(tp->TxDescArrays); - if (tp->RxDescArrays) - kfree(tp->RxDescArrays); + if (tp->TxDescArray) + pci_free_consistent(tp->pci_dev, + NUM_TX_DESC * sizeof (struct TxDesc) + 256, + tp->TxDescArray, tp->TxDescDmaAddr); + if (tp->RxDescArray) + pci_free_consistent(tp->pci_dev, + NUM_RX_DESC * sizeof (struct RxDesc) + 256, + tp->RxDescArray, tp->RxDescDmaAddr); return -ENOMEM; } - tp->RxBufferRings = kmalloc(RX_BUF_SIZE * NUM_RX_DESC, GFP_KERNEL); + tp->RxBufferRings = kmalloc(RX_BUF_SIZE * NUM_RX_DESC, GFP_KERNEL); if (tp->RxBufferRings == NULL) { printk(KERN_INFO "Allocate RxBufferRing failed\n"); } + tp->RxBufferDmas = pci_map_single(tp->pci_dev, tp->RxBufferRings, + RX_BUF_SIZE * NUM_RX_DESC, + PCI_DMA_FROMDEVICE); rtl8169_init_ring(dev); rtl8169_hw_start(dev); @@ -733,13 +740,13 @@ /* Set DMA burst size and Interframe Gap Time */ RTL_W32(TxConfig, - (TX_DMA_BURST << TxDMAShift) | (InterFrameGap << - TxInterFrameGapShift)); + (TX_DMA_BURST << TxDMAShift) | + (InterFrameGap << TxInterFrameGapShift)); tp->cur_rx = 0; - RTL_W32(TxDescStartAddr, virt_to_bus(tp->TxDescArray)); - RTL_W32(RxDescStartAddr, virt_to_bus(tp->RxDescArray)); + RTL_W32(TxDescStartAddr, tp->TxDescDmaAddr); + RTL_W32(RxDescStartAddr, tp->RxDescDmaAddr); RTL_W8(Cfg9346, Cfg9346_Lock); udelay(10); @@ -775,12 +782,17 @@ for (i = 0; i < NUM_RX_DESC; i++) { if (i == (NUM_RX_DESC - 1)) tp->RxDescArray[i].status = - (OWNbit | EORbit) + RX_BUF_SIZE; + (OWNbit | EORbit) | + __constant_cpu_to_le32(RX_BUF_SIZE); else - tp->RxDescArray[i].status = OWNbit + RX_BUF_SIZE; + tp->RxDescArray[i].status = OWNbit | + __constant_cpu_to_le32(RX_BUF_SIZE); tp->RxBufferRing[i] = &(tp->RxBufferRings[i * RX_BUF_SIZE]); - tp->RxDescArray[i].buf_addr = virt_to_bus(tp->RxBufferRing[i]); + tp->RxBufferDma[i] = + (dma_addr_t)((unsigned int)tp->RxBufferDmas + + i * RX_BUF_SIZE); + tp->RxDescArray[i].buf_addr = cpu_to_le32(tp->RxBufferDma[i]); } } @@ -842,15 +854,19 @@ if ((tp->TxDescArray[entry].status & OWNbit) == 0) { tp->Tx_skbuff[entry] = skb; - tp->TxDescArray[entry].buf_addr = virt_to_bus(skb->data); + tp->TxDescArray[entry].buf_addr = + cpu_to_le32(pci_map_single(tp->pci_dev, skb->data, + skb->len, PCI_DMA_TODEVICE)); if (entry != (NUM_TX_DESC - 1)) tp->TxDescArray[entry].status = - (OWNbit | FSbit | LSbit) | ((skb->len > ETH_ZLEN) ? - skb->len : ETH_ZLEN); + (OWNbit | FSbit | LSbit) | + cpu_to_le32((skb->len > ETH_ZLEN) ? + skb->len : ETH_ZLEN); else tp->TxDescArray[entry].status = (OWNbit | EORbit | FSbit | LSbit) | - ((skb->len > ETH_ZLEN) ? skb->len : ETH_ZLEN); + cpu_to_le32(((skb->len > ETH_ZLEN) ? + skb->len : ETH_ZLEN)); RTL_W8(TxPoll, 0x40); //set polling bit @@ -884,8 +900,14 @@ while (tx_left > 0) { if ((tp->TxDescArray[entry].status & OWNbit) == 0) { - dev_kfree_skb_irq(tp-> - Tx_skbuff[dirty_tx % NUM_TX_DESC]); + struct sk_buff *skb = + tp->Tx_skbuff[dirty_tx % NUM_TX_DESC]; + + pci_unmap_single(tp->pci_dev, + le32_to_cpu(tp->TxDescArray[entry]. + buf_addr), + skb->len, PCI_DMA_TODEVICE); + dev_kfree_skb_irq(skb); tp->Tx_skbuff[dirty_tx % NUM_TX_DESC] = NULL; tp->stats.tx_packets++; dirty_tx++; @@ -926,12 +948,16 @@ tp->stats.rx_crc_errors++; } else { pkt_size = - (int) (tp->RxDescArray[cur_rx]. - status & 0x00001FFF) - 4; + (int) (le32_to_cpu(tp->RxDescArray[cur_rx]. + status) & 0x00001FFF) - 4; skb = dev_alloc_skb(pkt_size + 2); if (skb != NULL) { skb->dev = dev; skb_reserve(skb, 2); // 16 byte align the IP fields. // + pci_dma_sync_single(tp->pci_dev, + tp->RxBufferDmas, + RX_BUF_SIZE * NUM_RX_DESC, + PCI_DMA_FROMDEVICE); eth_copy_and_sum(skb, tp->RxBufferRing[cur_rx], pkt_size, 0); skb_put(skb, pkt_size); @@ -940,13 +966,15 @@ if (cur_rx == (NUM_RX_DESC - 1)) tp->RxDescArray[cur_rx].status = - (OWNbit | EORbit) + RX_BUF_SIZE; + (OWNbit | EORbit) | + __constant_cpu_to_le32(RX_BUF_SIZE); else tp->RxDescArray[cur_rx].status = - OWNbit + RX_BUF_SIZE; + OWNbit | + __constant_cpu_to_le32(RX_BUF_SIZE); tp->RxDescArray[cur_rx].buf_addr = - virt_to_bus(tp->RxBufferRing[cur_rx]); + cpu_to_le32(tp->RxBufferDma[cur_rx]); dev->last_rx = jiffies; tp->stats.rx_bytes += pkt_size; tp->stats.rx_packets++; @@ -1045,12 +1073,16 @@ free_irq(dev->irq, dev); rtl8169_tx_clear(tp); - kfree(tp->TxDescArrays); - kfree(tp->RxDescArrays); - tp->TxDescArrays = NULL; - tp->RxDescArrays = NULL; + pci_free_consistent(tp->pci_dev, + NUM_TX_DESC * sizeof (struct TxDesc) + 256, + tp->TxDescArray, tp->TxDescDmaAddr); + pci_free_consistent(tp->pci_dev, + NUM_RX_DESC * sizeof (struct RxDesc) + 256, + tp->RxDescArray, tp->RxDescDmaAddr); tp->TxDescArray = NULL; tp->RxDescArray = NULL; + pci_unmap_single(tp->pci_dev, tp->RxBufferDmas, + RX_BUF_SIZE * NUM_RX_DESC, PCI_DMA_FROMDEVICE); kfree(tp->RxBufferRings); for (i = 0; i < NUM_RX_DESC; i++) { tp->RxBufferRing[i] = NULL; --fUYQa+Pmc3FrFX/N-- From cfriesen@nortelnetworks.com Thu Nov 6 06:52:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Nov 2003 06:52:59 -0800 (PST) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6EqQ25008051 for ; Thu, 6 Nov 2003 06:52:27 -0800 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA6EpaA23579; Thu, 6 Nov 2003 09:51:36 -0500 (EST) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WJGYASW9; Thu, 6 Nov 2003 09:51:36 -0500 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WLB8QF9X; Thu, 6 Nov 2003 09:51:36 -0500 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 171A12E151; Thu, 6 Nov 2003 09:51:35 -0500 (EST) Message-ID: <3FAA5FF6.50509@nortelnetworks.com> Date: Thu, 06 Nov 2003 09:51:34 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: kuznet@ms2.inr.ac.ru Cc: "David S. Miller" , jmorris@redhat.com, hadi@znyx.com, netdev@oss.sgi.com Subject: Re: Fw: issues with SO_PRIORITY and IP_TOS References: <200311060931.MAA14771@yakov.inr.ac.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1253 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev kuznet@ms2.inr.ac.ru wrote: > What's about VLAN thing, this approach enforces you to use > DSCP directly and never use skb->priority (well, to be more exact, > to use it when you have no another hints available: in this case > our skb->priority is _right_ hint) Okay, maybe you can help me out then. I would like to send a vlan tagged packet, with vlan priority of x and DSCP field of (x<<5). What is the proper way to do this, if I should not be using skb->priority? Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From masterpe@xs4all.nl Thu Nov 6 08:55:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Nov 2003 08:56:22 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6Gth25012486 for ; Thu, 6 Nov 2003 08:55:44 -0800 Received: from lawbox.int.mpe.xs4all.nl (mpe.xs4all.nl [213.84.237.99]) by smtpzilla3.xs4all.nl (8.12.9/8.12.9) with ESMTP id hA6GtgS0065381 for ; Thu, 6 Nov 2003 17:55:42 +0100 (CET) Subject: New found issues with forcedeth From: Laurens To: netdev@oss.sgi.com In-Reply-To: <1068059045.3618.3.camel@lawbox.int.mpe.xs4all.nl> References: <1068059045.3618.3.camel@lawbox.int.mpe.xs4all.nl> Content-Type: text/plain Message-Id: <1068137741.3611.9.camel@lawbox.int.mpe.xs4all.nl> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 06 Nov 2003 17:55:41 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 1254 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: masterpe@xs4all.nl Precedence: bulk X-list: netdev Further testing revealed several other problems, let me first start with my specs: Kernel: Linux 2.6.0-test9-mm2 Distro: Gentoo Base System version 1.4.3.11 CPU: AMD Athlon(tm) XP 2700+ Disk: Maxtor 6Y120P0 Ethernet: nVidia Corporation nForce2 XFree86: 4.3.0 Monitor: Iiyama AS4314UT, TFT-Master Pro 17 Videocard: nVidia Corporation NV15DDR [GeForce2 Ti] Audio: Creative Labs SB Live! EMU10k1 Issues: - dhcpcd eth0 takes longer to load - emerge sync (gentoo update tool) hangs in the middle of updating (confirmed not to happen with nvnet) - modprobe segfaulted on "modprobe -r forcedeth" (note: eth0 was not active) On the good side: - nvnet seems to mess up my framebuffer, forcedeth does not :) Should you require more information just ask. good luck, Lawrence From kaber@trash.net Thu Nov 6 09:52:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Nov 2003 09:53:30 -0800 (PST) Received: from gw.localnet (port-212-202-185-245.reverse.qdsl-home.de [212.202.185.245]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6Hqt25014355 for ; Thu, 6 Nov 2003 09:52:56 -0800 Received: from ws.localnet ([192.168.0.23] helo=trash.net) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1AHnpE-0000FU-00; Thu, 06 Nov 2003 18:21:40 +0100 Message-ID: <3FAA832A.6000505@trash.net> Date: Thu, 06 Nov 2003 18:21:46 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031024 Debian/1.5-2 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: [PATCH]: fix skb_copy_expand offset calculation Content-Type: multipart/mixed; boundary="------------080502050700020003090802" X-archive-position: 1255 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------080502050700020003090802 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi Dave, this patch fixes offset calculation in skb_copy_expand. head_copy_len = skb_headroom(skb); head_copy_off = 0; if (newheadroom < head_copy_len) { head_copy_off = head_copy_len - newheadroom; head_copy_len = newheadroom; } /* Copy the linear header and data. */ if (skb_copy_bits(skb, -head_copy_len, n->head + head_copy_off, skb->len + head_copy_len)) It looks like it is intended to copy as much as possible, cutting off bytes at the beginning is there is not enough room. For the case newheadroom < head_copy_len that means it needs to copy newheadroom bytes from skb->data - newheadroom to n->head, so head_copy_off needs to be 0. I don't know how the data copied is used later on but I assume it is intended to stay continous. That means in the case that newheadroom > skb_headroom(skb) we need to copy skb_headroom(skb) bytes to n->head + newheadroom - skb_headroom(skb), so head_copy_off becomes newheadroom - head_copy_len. In the patch the case newheadroom == skb_headroom(skb) is handled with the first condition to save either a jump or a subtraction. The patch is verified to fix the problem that led me to this, ipt_REJECT produced broken RSTs which triggered the "ipt_hook: happy cracking!" line in ip_conntrack_standalone.c. Best regards, Patrick --------------080502050700020003090802 Content-Type: text/plain; name="2.6-skb_copy_expand.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="2.6-skb_copy_expand.diff" # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1413 -> 1.1414 # net/core/skbuff.c 1.32 -> 1.33 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/11/06 kaber@trash.net 1.1414 # Fix skb_copy_expand offset calculation # -------------------------------------------- # diff -Nru a/net/core/skbuff.c b/net/core/skbuff.c --- a/net/core/skbuff.c Thu Nov 6 17:34:55 2003 +++ b/net/core/skbuff.c Thu Nov 6 17:34:55 2003 @@ -595,10 +595,10 @@ head_copy_len = skb_headroom(skb); head_copy_off = 0; - if (newheadroom < head_copy_len) { - head_copy_off = head_copy_len - newheadroom; + if (newheadroom <= head_copy_len) head_copy_len = newheadroom; - } + else + head_copy_off = newheadroom - head_copy_len; /* Copy the linear header and data. */ if (skb_copy_bits(skb, -head_copy_len, n->head + head_copy_off, --------------080502050700020003090802-- From kumarkr@us.ibm.com Thu Nov 6 11:59:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Nov 2003 12:00:18 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6Jxc25019173 for ; Thu, 6 Nov 2003 11:59:44 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA6JxPcF256458; Thu, 6 Nov 2003 14:59:25 -0500 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA6JxOJC167838; Thu, 6 Nov 2003 12:59:24 -0700 Subject: Re: [PATCH] panic during unregister_netdevice() To: Stephen Hemminger Cc: davem@redhat.com, krkumar@us.ibm.com, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Krishna Kumar Date: Thu, 6 Nov 2003 11:58:24 -0800 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 11/06/2003 12:59:24 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-archive-position: 1256 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev Actually, even the original code looks good, and if that panic'd, the following won't change that (verified it also). When unregister_netdev() is called by the driver, it first calls unregister_netdevice() which drops it's last ref to the dev, making it zero. unregister_netdev() then calls rtnl_unlock() which calls netdev_run_todo(), which calls netdev_wait_allrefs() and only after that succeeds, does the driver do a free_netdev(). So the dev should not be freed while the wait_ref() is executing, and the original code looks correct. I don't know if it is some corruption on my system, some hardware problem ? I will look some more, also try to get a different machine. - KK |---------+----------------------------> | | Stephen Hemminger| | | | | | Sent by: | | | netdev-bounce@oss| | | .sgi.com | | | | | | | | | 11/05/2003 05:09 | | | PM | | | | |---------+----------------------------> >-----------------------------------------------------------------------------------------------------------------| | | | To: Krishna Kumar/Beaverton/IBM@IBMUS | | cc: davem@redhat.com, krkumar@us.ltcfwd.linux.ibm.com, netdev@oss.sgi.com | | Subject: Re: [PATCH] panic during unregister_netdevice() | | | >-----------------------------------------------------------------------------------------------------------------| Try this. Instead of dropping the last reference in unregister, it does it after all other references are gone (sort of like the old 2.4 code). diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Wed Nov 5 17:04:57 2003 +++ b/net/core/dev.c Wed Nov 5 17:04:57 2003 @@ -2743,7 +2743,7 @@ unsigned long rebroadcast_time, warning_time; rebroadcast_time = warning_time = jiffies; - while (atomic_read(&dev->refcnt) != 0) { + while (atomic_read(&dev->refcnt) > 1) { if (time_after(jiffies, rebroadcast_time + 1 * HZ)) { rtnl_shlock(); rtnl_exlock(); @@ -2838,6 +2838,7 @@ dev->reg_state = NETREG_UNREGISTERED; netdev_wait_allrefs(dev); + dev_put(dev); /* paranoia */ BUG_ON(atomic_read(&dev->refcnt)); @@ -2974,7 +2975,6 @@ /* Finish processing unregister after unlock */ net_set_todo(dev); - dev_put(dev); return 0; } From davem@pizda.ninka.net Thu Nov 6 12:05:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Nov 2003 12:06:25 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6K5d25019642 for ; Thu, 6 Nov 2003 12:05:51 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id LAA21388; Thu, 6 Nov 2003 11:59:36 -0800 Date: Thu, 6 Nov 2003 11:59:35 -0800 From: "David S. Miller" To: Krishna Kumar Cc: shemminger@osdl.org, krkumar@us.ibm.com, netdev@oss.sgi.com Subject: Re: [PATCH] panic during unregister_netdevice() Message-Id: <20031106115935.0cd56745.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1257 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 6 Nov 2003 11:58:24 -0800 Krishna Kumar wrote: > When unregister_netdev() is called by the driver, it first calls > unregister_netdevice() which > drops it's last ref to the dev, making it zero. unregister_netdev() then > calls rtnl_unlock() which > calls netdev_run_todo(), which calls netdev_wait_allrefs() and only after > that succeeds, > does the driver do a free_netdev(). So the dev should not be freed while > the wait_ref() is > executing, and the original code looks correct. That's correct. > I don't know if it is some corruption on my system, some hardware problem ? > I will look > some more, also try to get a different machine. It could be some 'user after free' or similar issue. Just an idea of something else to look for. My earlier comments about "putting to zero multiple times" were misguided, I forgot that these days dev_put() just decrements the count and does not do anything special when the count reaches zero. From davem@pizda.ninka.net Thu Nov 6 12:25:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Nov 2003 12:26:02 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6KPS25023260 for ; Thu, 6 Nov 2003 12:25:28 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA21548; Thu, 6 Nov 2003 12:20:11 -0800 Date: Thu, 6 Nov 2003 12:20:11 -0800 From: "David S. Miller" To: Patrick McHardy Cc: netdev@oss.sgi.com Subject: Re: [PATCH]: fix skb_copy_expand offset calculation Message-Id: <20031106122011.49d18674.davem@redhat.com> In-Reply-To: <3FAA832A.6000505@trash.net> References: <3FAA832A.6000505@trash.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1258 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 06 Nov 2003 18:21:46 +0100 Patrick McHardy wrote: > The patch is verified to fix the problem that led me to this, ipt_REJECT > produced broken RSTs which triggered the "ipt_hook: happy cracking!" > line in ip_conntrack_standalone.c. Great work Patrick, your analysis and fix is definitely correct. Patch applied, thanks. From davem@pizda.ninka.net Thu Nov 6 12:52:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Nov 2003 12:52:51 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6KqE25024023 for ; Thu, 6 Nov 2003 12:52:17 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA21675; Thu, 6 Nov 2003 12:46:59 -0800 Date: Thu, 6 Nov 2003 12:46:59 -0800 From: "David S. Miller" To: Ben Greear Cc: netdev@oss.sgi.com Subject: Re: [PATCH] 802.1q vlan updates Message-Id: <20031106124659.109c0d5c.davem@redhat.com> In-Reply-To: <3FA9CD0B.8000707@candelatech.com> References: <3FA9CD0B.8000707@candelatech.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1259 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 05 Nov 2003 20:24:43 -0800 Ben Greear wrote: > Here is a patch that is a cleaned up version of something I sent > a while back. This adds the ability to query a device to see if > it is a vlan device by asking for the vlan's parent device. > One can deduce that a querried interface is not a VLAN by looking > at the IOCTL error code. > > Patch is against 2.4.22-pre9, compile tested and extracted from a run-time > tested patch. I'll push this to Marcelo for 2.4.24, thanks. If you could cook up and test a 2.6.x version, I'll push that in for 2.6.1 From greearb@candelatech.com Thu Nov 6 13:01:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Nov 2003 13:01:34 -0800 (PST) Received: from grok.yi.org (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6L1025024474 for ; Thu, 6 Nov 2003 13:01:01 -0800 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id hA6L0sQN002798; Thu, 6 Nov 2003 13:00:55 -0800 Message-ID: <3FAAB686.1090004@candelatech.com> Date: Thu, 06 Nov 2003 13:00:54 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: [PATCH] 802.1q vlan updates References: <3FA9CD0B.8000707@candelatech.com> <20031106124659.109c0d5c.davem@redhat.com> In-Reply-To: <20031106124659.109c0d5c.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1260 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev David S. Miller wrote: > On Wed, 05 Nov 2003 20:24:43 -0800 > Ben Greear wrote: > > >>Here is a patch that is a cleaned up version of something I sent >>a while back. This adds the ability to query a device to see if >>it is a vlan device by asking for the vlan's parent device. >>One can deduce that a querried interface is not a VLAN by looking >>at the IOCTL error code. >> >>Patch is against 2.4.22-pre9, compile tested and extracted from a run-time >>tested patch. > > > I'll push this to Marcelo for 2.4.24, thanks. > > If you could cook up and test a 2.6.x version, I'll push that in > for 2.6.1 I have yet to start using 2.6, but I'll get a test system up as soon as 2.6.0 comes out and will send a patch shortly there-after. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From krkumar@us.ibm.com Thu Nov 6 13:10:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Nov 2003 13:11:19 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6LAV25025331 for ; Thu, 6 Nov 2003 13:10:44 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA6LAJIw232736; Thu, 6 Nov 2003 16:10:19 -0500 Received: from DYN318430BLD.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA6LAFJD156620; Thu, 6 Nov 2003 14:10:16 -0700 Date: Thu, 6 Nov 2003 13:07:57 -0800 (PST) From: Krishna Kumar X-X-Sender: krkumar@DYN318430BLD.beaverton.ibm.com To: "David S. Miller" cc: Krishna Kumar , , Subject: Re: [PATCH] panic during unregister_netdevice() In-Reply-To: <20031106115935.0cd56745.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1261 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev I think I found the problem in the link event code. linkwatch_event() calls rtnl_unlock() when it gets an event (UNREGISTER) for the device going down. But this gets called before the device unregister gets called, via the rmmod/pci_device_remove), and frees up the dev. Later the device unregister code panics the system. I also noticed that this panic happens for e100 but not for the 3com driver. 3com doesn't generate events for up/down using the linkwatch. I tested with the following patch, and the panic disappeared (the device shutdown properly). Dave, any need for rtnl_unlock() in this code ? Thanks, - KK diff -ruN linux-2.6.0-test9-bk9/net/core/link_watch.c linux-2.6.0-test9-bk9.new/net/core/link_watch.c --- linux-2.6.0-test9-bk9/net/core/link_watch.c 2003-11-06 12:26:30.000000000 -0800 +++ linux-2.6.0-test9-bk9.new/net/core/link_watch.c 2003-11-06 12:25:41.000000000 -0800 @@ -15,6 +15,7 @@ #include #include #include +#include #include #include #include @@ -89,9 +90,11 @@ linkwatch_nextevent = jiffies + HZ; clear_bit(LW_RUNNING, &linkwatch_flags); - rtnl_lock(); + rtnl_shlock(); + rtnl_exlock(); linkwatch_run_queue(); - rtnl_unlock(); + rtnl_exunlock(); + rtnl_shunlock(); } On Thu, 6 Nov 2003, David S. Miller wrote: > On Thu, 6 Nov 2003 11:58:24 -0800 > Krishna Kumar wrote: > > > When unregister_netdev() is called by the driver, it first calls > > unregister_netdevice() which > > drops it's last ref to the dev, making it zero. unregister_netdev() then > > calls rtnl_unlock() which > > calls netdev_run_todo(), which calls netdev_wait_allrefs() and only after > > that succeeds, > > does the driver do a free_netdev(). So the dev should not be freed while > > the wait_ref() is > > executing, and the original code looks correct. > > That's correct. > > > I don't know if it is some corruption on my system, some hardware problem ? > > I will look > > some more, also try to get a different machine. > > It could be some 'user after free' or similar issue. > Just an idea of something else to look for. > > My earlier comments about "putting to zero multiple times" were > misguided, I forgot that these days dev_put() just decrements the > count and does not do anything special when the count reaches zero. > > From davem@pizda.ninka.net Thu Nov 6 13:20:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Nov 2003 13:21:12 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6LKH25026121 for ; Thu, 6 Nov 2003 13:20:37 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id NAA21779; Thu, 6 Nov 2003 13:14:57 -0800 Date: Thu, 6 Nov 2003 13:14:57 -0800 From: "David S. Miller" To: Krishna Kumar Cc: kumarkr@us.ibm.com, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] panic during unregister_netdevice() Message-Id: <20031106131457.384694a5.davem@redhat.com> In-Reply-To: References: <20031106115935.0cd56745.davem@redhat.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1262 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 6 Nov 2003 13:07:57 -0800 (PST) Krishna Kumar wrote: > I tested with the following patch, and the panic disappeared (the > device shutdown properly). Dave, any need for rtnl_unlock() in this > code ? This linkwatch code never generates new entries on the netdev todo list so your patch looks fine. I'm going to apply it, thanks a lot. From charles@bueche.ch Thu Nov 6 14:02:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Nov 2003 14:03:33 -0800 (PST) Received: from james.netnea.com (ns1.netnea.com [138.189.116.70]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6M2u25028464 for ; Thu, 6 Nov 2003 14:02:58 -0800 Received: from bluez.bueche.ch (adsl-212-101-16-88.solnet.ch [212.101.16.88]) by james.netnea.com (8.12.10+Sun/8.12.2) with ESMTP id hA6M2l9k007238; Thu, 6 Nov 2003 23:02:47 +0100 (MET) Received: from localhost.solnet.ch (localhost [127.0.0.1]) by bluez.bueche.ch (Postfix) with ESMTP id 241CA143FC; Thu, 6 Nov 2003 23:02:44 +0100 (MET) Subject: Re: changing MTU on b44 breaks eth0 From: Charles Bueche To: Pekka Pietikainen Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20031104111555.GA26860@ee.oulu.fi> References: <1067888106.3366.20.camel@bluez.bueche.ch> <20031103205335.GA7668@ee.oulu.fi> <20031103151618.79704b30.davem@redhat.com> <20031104111555.GA26860@ee.oulu.fi> Content-Type: text/plain Message-Id: <1068156163.3496.8.camel@bluez.bueche.ch> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 06 Nov 2003 23:02:44 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 1263 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: charles@bueche.ch Precedence: bulk X-list: netdev Hi all, sorry for the late answer. I tried to apply the patch mentionned below, and it reject at Hunk #1. I run linux 2.4.22, my b44.c carry version 0.9. Can you please send me the full b44.c file so I can try again ? I'm a bit unsure wheter I should try anyway, your discussions are not very understable to me. Pardon my ignorance of kernel dumps :-) I would be very happy if I could simply recompile this particular module, and not my full kernel after patching a single file. Is there a way to find the commands originaly used to compile and link this module from some logs ? Regards, Charles On Tue, 2003-11-04 at 12:15, Pekka Pietikainen wrote: > On Mon, Nov 03, 2003 at 03:16:18PM -0800, David S. Miller wrote: > > I think Jeff should merge this upstrea, but I really disagree > > with the CONFIG_PM ifdefs for the power-management support. > Fine with me (patch with CONFIG_PM removed included) > > Oh btw., when trying out whether the new code even compiles/loads > I got the following in rmmod, does it look like something caused > by generic code or should I look for a reason in b44? :-) > (This is 2.6.0-test9-bk6). > > kernel BUG at net/core/dev.c:2882! > invalid operand: 0000 [#1] > CPU: 0 > EIP: 0060:[] Tainted: P > EFLAGS: 00010297 > EIP is at free_netdev+0x2d/0x40 > eax: ddfd6800 ebx: ddfd6800 ecx: 1f2e9da0 edx: 00000003 > esi: dff5d000 edi: dff5d054 ebp: de743ec4 esp: de743ec4 > ds: 007b es: 007b ss: 0068 > Process rmmod (pid: 18966, threadinfo=de742000 task=c797b320) > Stack: de743edc e090011d ddfd6800 dff5d000 e0902544 00000000 de743eec > c01c8c09 > dff5d000 dff5d054 de743f04 c0210dd0 dff5d054 dff5d080 e0902590 > e0902590 > de743f18 c0210e02 dff5d054 e0902544 c02fb458 de743f2c c0211039 > e0902544 > Call Trace: > [] b44_remove_one+0x3d/0x60 [b44] > [] pci_device_remove+0x39/0x40 > [] device_release_driver+0x60/0x70 > [] driver_detach+0x22/0x40 > [] bus_remove_driver+0x39/0x70 > [] driver_unregister+0x14/0x26 > [] pci_unregister_driver+0x17/0x30 > [] b44_cleanup+0x12/0x14 [b44] > [] sys_delete_module+0x113/0x190 > [] do_munmap+0x14f/0x1b0 > [] sys_munmap+0x43/0x60 > [] sysenter_past_esp+0x52/0x71 > > Code: 0f 0b 42 0b ab 48 2e c0 eb de c9 e9 93 6e ef ff 8d 76 00 55 > > Trying to reproduce on a fresh non-nvidia-tainted -bk8 rmmod initially worked, > then I did /sbin/modprobe b44; /sbin/ifup eth0; /sbin/rmmod b44 > managed to trigger another race: > > eth0: no IPv6 routers present > Unable to handle kernel paging request at virtual address 706647ef > printing eip: > c0254415 > *pde = 00000000 > Oops: 0000 [#1] > CPU: 0 > EIP: 0060:[] Not tainted > EFLAGS: 00010216 > EIP is at rtnetlink_fill_ifinfo+0x2a5/0x480 > eax: 706647e3 ebx: df037800 ecx: 00000ee4 edx: c68fa09c > esi: 00000000 edi: df037805 ebp: dff8deb4 esp: dff8de88 > ds: 007b es: 007b ss: 0068 > Process events/0 (pid: 3, threadinfo=dff8c000 task=c151cc80) > Stack: c689fd80 00000004 00000004 dff8dea4 00000ee4 00000f60 c68fa000 > 000005dc > c689fd80 ffffffff 00000011 dff8dee4 c02548ac c689fd80 df037800 > 00000011 > 00000000 00000000 ffffffff df037800 c0335c00 df037800 00000006 > dff8def8 > Call Trace: > [] rtmsg_ifinfo+0x5c/0xd0 > [] rtnetlink_event+0x35/0x62 > [] notifier_call_chain+0x2d/0x50 > [] netdev_wait_allrefs+0xc0/0x110 > [] netdev_run_todo+0x10c/0x1f0 > [] __down_failed+0xb/0x14 > [] worker_thread+0x1bb/0x2a0 > [] linkwatch_event+0x0/0x30 > [] default_wake_function+0x0/0x30 > [] ret_from_fork+0x6/0x14 > [] default_wake_function+0x0/0x30 > [] worker_thread+0x0/0x2a0 > [] kernel_thread_helper+0x5/0xc > > Code: 8b 50 0c b9 ff ff ff ff 31 c0 83 c2 08 89 d7 f2 ae f7 d1 49 > > --- /usr/src/linux-2.6.0-0.test9.1.67/drivers/net/b44.c 2003-10-25 21:43:30.000000000 +0300 > +++ linux-2.6.0-test9/drivers/net/b44.c 2003-11-04 12:32:13.403426192 +0200 > @@ -25,8 +25,8 @@ > > #define DRV_MODULE_NAME "b44" > #define PFX DRV_MODULE_NAME ": " > -#define DRV_MODULE_VERSION "0.91" > -#define DRV_MODULE_RELDATE "Oct 3, 2003" > +#define DRV_MODULE_VERSION "0.92" > +#define DRV_MODULE_RELDATE "Nov 4, 2003" > > #define B44_DEF_MSG_ENABLE \ > (NETIF_MSG_DRV | \ > @@ -942,6 +942,8 @@ > b44_init_hw(bp); > spin_unlock_irq(&bp->lock); > > + b44_enable_ints(bp); > + > return 0; > } > > @@ -1558,6 +1560,8 @@ > netif_wake_queue(bp->dev); > spin_unlock_irq(&bp->lock); > > + b44_enable_ints(bp); > + > return 0; > } > case ETHTOOL_GPAUSEPARAM: { > @@ -1601,6 +1605,8 @@ > } > spin_unlock_irq(&bp->lock); > > + b44_enable_ints(bp); > + > return 0; > } > }; > @@ -1852,11 +1858,53 @@ > } > } > > +static int b44_suspend(struct pci_dev *pdev, u32 state) > +{ > + struct net_device *dev = pci_get_drvdata(pdev); > + struct b44 *bp = dev->priv; > + > + if (!netif_running(dev)) > + return 0; > + > + del_timer_sync(&bp->timer); > + > + spin_lock_irq(&bp->lock); > + > + b44_halt(bp); > + netif_carrier_off(bp->dev); > + netif_device_detach(bp->dev); > + b44_free_rings(bp); > + > + spin_unlock_irq(&bp->lock); > + return 0; > +} > + > +static int b44_resume(struct pci_dev *pdev) > +{ > + struct net_device *dev = pci_get_drvdata(pdev); > + struct b44 *bp = dev->priv; > + > + if (!netif_running(dev)) > + return 0; > + > + spin_lock_irq(&bp->lock); > + > + b44_init_rings(bp); > + b44_init_hw(bp); > + netif_device_attach(bp->dev); > + spin_unlock_irq(&bp->lock); > + > + b44_enable_ints(bp); > + return 0; > +} > + > static struct pci_driver b44_driver = { > .name = DRV_MODULE_NAME, > .id_table = b44_pci_tbl, > .probe = b44_init_one, > .remove = __devexit_p(b44_remove_one), > + .suspend = b44_suspend, > + .resume = b44_resume, > }; > > static int __init b44_init(void) -- Charles Bueche sand, snow, wave, wind and net -surfer From fdonzet@yahoo.fr Fri Nov 7 00:38:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 07 Nov 2003 00:39:17 -0800 (PST) Received: from web25202.mail.ukl.yahoo.com (web25202.mail.ukl.yahoo.com [217.12.10.62]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA78co25006908 for ; Fri, 7 Nov 2003 00:38:51 -0800 Message-ID: <20031107083844.74787.qmail@web25202.mail.ukl.yahoo.com> Received: from [195.68.44.148] by web25202.mail.ukl.yahoo.com via HTTP; Fri, 07 Nov 2003 09:38:44 CET Date: Fri, 7 Nov 2003 09:38:44 +0100 (CET) From: =?iso-8859-1?q?francois=20donzet?= Subject: problem in driver network code To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 1264 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fdonzet@yahoo.fr Precedence: bulk X-list: netdev Hi all I am writing my own ethernet driver, and i have a little question on checksum offloading : I am trying to understand the role of skb->csum. I've read some code, and see that it is filled (for example in e100 code) by the sum of all words excepting the ethernet II header. The fact is, on an input path, if CHECKSUM_HW is set, TCP uses skb->csum to verify the complete checksum (adding the pseudo header one). It seems to me that there is a problem ;). If i store in skb->csum a sum of all words of the packet data, it will be unusable by tcp (the skb->csum doesn't contain the checksum of tcpheader plus data only, as the ipheader is part of the packet when the sum is computed) What do i miss ? I think the skb->csum MUST at one point contain only a sum on tcpheader+data. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com From hadi@cyberus.ca Fri Nov 7 05:28:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 07 Nov 2003 05:28:41 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA7DSO25021508 for ; Fri, 7 Nov 2003 05:28:24 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1AI6f0-0006LJ-6J; Fri, 07 Nov 2003 08:28:22 -0500 Subject: Re: Announce: NetKeeper Firewall For Linux From: jamal Reply-To: hadi@cyberus.ca To: Emmanuel Fleury Cc: "David S. Miller" , netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, Mikkel Christiansen In-Reply-To: <1068114376.1532.115.camel@rade7.s.cs.auc.dk> References: <1067285612.552.9.camel@aphrodite.olympus.net> <20031028014223.129933be.davem@redhat.com> <1067335655.10628.7.camel@rade7.s.cs.auc.dk> <1068001237.1064.31.camel@jzny.localdomain> <1068046114.31636.92.camel@rade7.s.cs.auc.dk> <1068089345.1020.17.camel@jzny.localdomain> <1068114376.1532.115.camel@rade7.s.cs.auc.dk> Content-Type: text/plain; charset=ISO-8859-1 Organization: jamalopolis Message-Id: <1068211670.1031.49.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Nov 2003 08:27:50 -0500 Content-Transfer-Encoding: 8bit X-archive-position: 1265 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Thu, 2003-11-06 at 05:26, Emmanuel Fleury wrote: > Ok, actually we were so focused on the classification scheme that we > didn't really try to do something nice for the actions... In a matter of > facts, we have only one action (log) and it is not even implemented. > > So, we will definitely look at your code to avoid us to have to think > about this part (and avoid to have to recode the actions). > I am asking you to switch to the TC code. I dont think i am making my point across ;->[1]. Integrate your classifer like any other tc classifier and then you dont have to look at my code unless you really want to. > > Anything that requires "connection setup" to dynamically add rules is a > > candidate. Think Voip SIP Proxy server for example which will insert > > rules; think any authentication schemes that are needed before > > installing rules, think tcp-splicing etc. > > Ok, but you are speaking about non permanent rules (aka dynamic rules). > These types are most dominant these days in my opinion unless you are a single user behind a DSL line. > The idea we have to handle stateful inspection is to have the core > filter (totally static) plus some "state" nodes placed inside the IDD > which are calling a function to evaluate the "state" of the packet > (based on some informations given by the packet header and a database of > the open connections). Isnt the state database another classifier and therefore you will be faced with the same challenges for it? I dont think you wuill get a free ride putting the state lookups somewhere else. > When reaching the terminals, one of the action > can be to change the state of the connection. tc allows you to have multiple cascaded classifiers; so you could "reclassify" and jump to a state classifier. I think the other guys from .dk also had their own scheme of achieving the same goal. Being able to do this in my opinion is architecturally cleaner. > I guess that what you describe can be handled by such mechanism > (better than changing the ruleset each time). As it is handled outside > of the IDD, this take only the time of the look-up in the database and > the time to modify the database (when necessary). > This is true if you consider the state database to be a different problem other than a classification one. > But, I over simplified things here, this scheme is far from being ready > at this point. We should investigate it more in depth (we need more > time!!!). > no problem. > > I think thats a design issue. For example while u32 classifier may not > > process as fast as you (lookups would take longer relatively ) - its > > insertion time is independent of the complexity of the rules. > > Lakshman (sp?) had a good paper on the tradeoffs between memory space > > used, lookup times and insertion times (there was another variable) and > > i think he may have proved you cant have all of them work well at the > > same time. > > Ok. Could you give more details about the references of this paper from > Lakshman ? > You are in academia, you better make sure you are aware of these things ;-> The Lakshman paper describes an algorithm but i remember it was the first to introduce classification constraints: T.V.Lakshman and D.Stiliadis. High Speed Policy-based Packet Forwarding Using Efficient Multi-dimensional Range Matching. Proceedings of ACM Sigcomm98 Another good paper to look at is: A.Feldmann and S.Muthukrishnan. Tradeoffs for packet classification. Proceedings of IEEE Infocom2000 > I am wrong here, terribly wrong. The thing is that is you add a rule at > the end of your filter, you will not have to rebuild it, but inserting a > rule randomly in the list is... bad. For now, we don't have any good > algorithm to insert a rule, so we just rebuild the whole thing. > Then you have some work to do > > > When coding in the kernel, we are coding with the idea that: > > > « The kernel should defend itself against user-space. » > > > > > > So, when the user say: "Commit". > > > > > > The kernel will first check the decision diagram for safety (no NULL > > > pointers, out of range variables, no loops, etc) and depending of the > > > tests, will take the decision to commit or not. > > > > That sounds more like still a user space problem ;-> > > No. > > Users shouldn't be able to break the kernel just by misconfiguring it. > Couldnt you, knowing the rules already existing check for breakage in user space? > > I saw in your paper briefly that you have infact a checker for something > > like this. > > If you are speaking about the "network access verifier", it is something > totally different. But, I might have misunderstood you. > I meant that network access verifier. I believe you should be able to verify things not only just in user space bu even in a remote location (example a network management station). Now this stuff is interesting. > > In my view the most important issues in priority order are: > > lookup speed regardless of table size, insert/delete rate regardless of > > table size, Capacity (should be able to go to the hundreds of thousands > > of flows), memory use for storage purposes - although i dont really care > > very much about these since memory is cheap these days. > > Ok, I think we have to work on the insert/delete part. I know for a fact > that insert/delete inside the IDD is not an option (as the complexity of > this operation is too high), so we will look at some other way to handle > it. > cool. Looking forward to see some of your thoughts on this when you have experienced it. cheers, jamal [1] Look at your action code dispatch name and my old one and note the name being _exactly_ the same. I dont think it is a big coincidence and i dont think you had any bad intent. I am just saying you can continue doing that or you can integrate. Why dont we drop this part of the discussion if you dont wanna move forward to the tc code? I thought you agreed with Dave to integrate ;-> From rask@sygehus.dk Fri Nov 7 09:17:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 07 Nov 2003 09:17:32 -0800 (PST) Received: from 0x50a41c03.albnxx15.adsl-dhcp.tele.dk (0x50a41c03.albnxx15.adsl-dhcp.tele.dk [80.164.28.3]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA7HHE25025248 for ; Fri, 7 Nov 2003 09:17:15 -0800 Received: by 0x50a41c03.albnxx15.adsl-dhcp.tele.dk (Postfix, from userid 500) id 883EB2C69D; Fri, 7 Nov 2003 18:15:13 +0100 (CET) Date: Fri, 7 Nov 2003 18:15:12 +0100 From: Rask Ingemann Lambertsen To: francois donzet Cc: netdev@oss.sgi.com Subject: Re: problem in driver network code Message-ID: <20031107181508.A1102@sygehus.dk> References: <20031107083844.74787.qmail@web25202.mail.ukl.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031107083844.74787.qmail@web25202.mail.ukl.yahoo.com>; from fdonzet@yahoo.fr on Fri, Nov 07, 2003 at 09:38:44AM +0100 X-archive-position: 1266 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rask@sygehus.dk Precedence: bulk X-list: netdev On Fri, Nov 07, 2003 at 09:38:44AM +0100, francois donzet wrote: > > It seems to me that there is a problem ;). If i store > in skb->csum a sum of all words of the packet data, it > will be unusable by tcp (the skb->csum doesn't > contain the checksum of tcpheader plus data only, as > the ipheader is part of the packet when the sum is > computed) That can be accounted for by the TCP code because the IP header is known to the TCP code. IIRC, the pseudoheader is similiar to a real IP header, so it may take just a few lines of code to make up for the difference, but I haven't checked that. What do you do with an IEEE 802.1q (VLAN) or 802.2 (LLC) packet? The VLAN code in vlan_skb_recv() does not adjust skb->csum or skb->ip_summed. Neither does the 802.2 code. -- Regards, Rask Ingemann Lambertsen From krkumar@us.ibm.com Fri Nov 7 11:04:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 07 Nov 2003 11:04:24 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA7J4325027470 for ; Fri, 7 Nov 2003 11:04:09 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA7J3vcF452612; Fri, 7 Nov 2003 14:03:57 -0500 Received: from [9.47.18.241] (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA7J3tZ9324764; Fri, 7 Nov 2003 12:03:56 -0700 Date: Fri, 7 Nov 2003 11:01:41 -0800 (PST) From: Krishna Kumar X-X-Sender: krkumar@linux.local To: "David S. Miller" cc: netdev@oss.sgi.com, Subject: [PATCH] Hang in downing interface with IPv6 PRIVACY In-Reply-To: <20031106115935.0cd56745.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1267 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev While using PRIVACY extensions, I sometimes get a hang when I remove the interface. But I can reproduce this every time using the test script at the end of the mail (hang depends on the order of address deletion). The bug is in ipv6_del_addr() where if a temp address is being deleted, it does an __in6_ifa_put() of the main address from which it was derived (basically the autoconf prefix address). So if the main address was deleted first, it's ifp ref count would be 1 and it would 'wait' to be freed till it's temp address was freed first. When the temp address is deleted, the __put() routine drops the main address's ifp ref count to 0, but not free it. unregister_netdevice() hangs giving message that ref count is 1. Fix tested overnight. Also, the code at the top of the routine is unnecessary, the same is being done when the address is found a little later in that routine. Thanks, - KK -------------------------- PATCH ----------------------------------------- diff -ruN linux-2.6.0-test9-bk9/net/ipv6/addrconf.c linux-2.6.0-test9-bk9.new/net/ipv6/addrconf.c --- linux-2.6.0-test9-bk9/net/ipv6/addrconf.c 2003-11-07 10:56:42.000000000 -0800 +++ linux-2.6.0-test9-bk9.new/net/ipv6/addrconf.c 2003-11-07 10:56:50.000000000 -0800 @@ -571,15 +571,6 @@ ifp->dead = 1; -#ifdef CONFIG_IPV6_PRIVACY - spin_lock_bh(&ifp->lock); - if (ifp->ifpub) { - __in6_ifa_put(ifp->ifpub); - ifp->ifpub = NULL; - } - spin_unlock_bh(&ifp->lock); -#endif - write_lock_bh(&addrconf_hash_lock); for (ifap = &inet6_addr_lst[hash]; (ifa=*ifap) != NULL; ifap = &ifa->lst_next) { @@ -600,7 +591,7 @@ if (ifa == ifp) { *ifap = ifa->tmp_next; if (ifp->ifpub) { - __in6_ifa_put(ifp->ifpub); + in6_ifa_put(ifp->ifpub); ifp->ifpub = NULL; } __in6_ifa_put(ifp); ----------------------- TEST PROGRAM ------------------------------------ insmod /lib/modules/2.6.0-test9-bk9/kernel/drivers/net/e100/e100.ko ifup eth0 # enable privacy address creation echo 1 > /proc/sys/net/ipv6/conf/eth0/use_tempaddr # set router, get autoconf/privacy addresses echo 1 > /proc/sys/net/ipv6/conf/all/forwarding radvd echo 0 > /proc/sys/net/ipv6/conf/all/forwarding # wait for radvd to configure interface addresses sleep 10 # kill radvd (paranoia) kill `ps -ef|grep radvd|grep -v grep|awk '{print $2}'` # delete last regular address first! (happens to be regular :-) ifconfig eth0 del `ifconfig eth0 | grep Site | tail -1 | awk '{print $3}'` # now delete all other addresses. bug happens here when the temp address # is deleted, it doesn't free the regular addresses 'ifp'. for i in `ifconfig eth0 | grep Site | awk '{print $3}'` do ifconfig eth0 del $i done ifdown eth0 rmmod e100 From steiner@sgi.com Fri Nov 7 14:37:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 07 Nov 2003 14:37:50 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA7Mba25000800 for ; Fri, 7 Nov 2003 14:37:36 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA7Mv7Hc003189 for ; Fri, 7 Nov 2003 16:57:07 -0600 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA7MbUP513415548 for ; Fri, 7 Nov 2003 16:37:30 -0600 (CST) Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA7MbT0L22539445 for ; Fri, 7 Nov 2003 16:37:29 -0600 (CST) Received: (from steiner@localhost) by attica.americas.sgi.com (8.11.6/8.11.6/erikj-RedHat-7.2-Eagan) id hA7MbT223824 for netdev@oss.sgi.com; Fri, 7 Nov 2003 16:37:29 -0600 Date: Fri, 7 Nov 2003 16:37:29 -0600 From: Jack Steiner To: netdev@oss.sgi.com Subject: FW: [PATCH] - Incorrect cpumask definition in net/core/flow.c Message-ID: <20031107223729.GA20687@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 1268 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steiner@sgi.com Precedence: bulk X-list: netdev (I sent this to akpm earlier - I think I sent it to the wrong list) This fixes a problem in net/core/flow.c. The field "cpumap" is defined as a "unsigned long". It should be a "cpumask_t". # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1402 -> 1.1403 # net/core/flow.c 1.15 -> 1.16 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/11/07 steiner@attica.americas.sgi.com 1.1403 # Change cpumap definition from "unsigned long" to "cpumask_t". # -------------------------------------------- # diff -Nru a/net/core/flow.c b/net/core/flow.c --- a/net/core/flow.c Fri Nov 7 15:04:08 2003 +++ b/net/core/flow.c Fri Nov 7 15:04:08 2003 @@ -65,7 +65,7 @@ struct flow_flush_info { atomic_t cpuleft; - unsigned long cpumap; + cpumask_t cpumap; struct completion completion; }; static DEFINE_PER_CPU(struct tasklet_struct, flow_flush_tasklets) = { NULL }; @@ -73,7 +73,7 @@ #define flow_flush_tasklet(cpu) (&per_cpu(flow_flush_tasklets, cpu)) static DECLARE_MUTEX(flow_cache_cpu_sem); -static unsigned long flow_cache_cpu_map; +static cpumask_t flow_cache_cpu_map; static unsigned int flow_cache_cpu_count; static void flow_cache_new_hashrnd(unsigned long arg) -- Thanks Jack Steiner (steiner@sgi.com) 651-683-5302 Principal Engineer SGI - Silicon Graphics, Inc. From akpm@osdl.org Fri Nov 7 15:43:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 07 Nov 2003 15:43:54 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA7Nhd25001941 for ; Fri, 7 Nov 2003 15:43:39 -0800 Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id hA7NhQC03864; Fri, 7 Nov 2003 15:43:27 -0800 Date: Fri, 7 Nov 2003 15:43:55 -0800 From: Andrew Morton To: "David S. Miller" Cc: netdev@oss.sgi.com, Jack Steiner Subject: Fw: [PATCH] - Incorrect cpumask definition in net/core/flow.c Message-Id: <20031107154355.74fe4fd4.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1269 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev One for you please Dave. Begin forwarded message: Date: Fri, 7 Nov 2003 15:08:48 -0600 From: Jack Steiner To: akpm@osdl.org, linux-kernel@vger.kernel.org Cc: Jesse Barnes Subject: [PATCH] - Incorrect cpumask definition in net/core/flow.c This fixes a problem in net/core/flow.c. The field "cpumap" is defined as a "unsigned long". It should be a "cpumask_t". # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1402 -> 1.1403 # net/core/flow.c 1.15 -> 1.16 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/11/07 steiner@attica.americas.sgi.com 1.1403 # Change cpumap definition from "unsigned long" to "cpumask_t". # -------------------------------------------- # diff -Nru a/net/core/flow.c b/net/core/flow.c --- a/net/core/flow.c Fri Nov 7 15:04:08 2003 +++ b/net/core/flow.c Fri Nov 7 15:04:08 2003 @@ -65,7 +65,7 @@ struct flow_flush_info { atomic_t cpuleft; - unsigned long cpumap; + cpumask_t cpumap; struct completion completion; }; static DEFINE_PER_CPU(struct tasklet_struct, flow_flush_tasklets) = { NULL }; @@ -73,7 +73,7 @@ #define flow_flush_tasklet(cpu) (&per_cpu(flow_flush_tasklets, cpu)) static DECLARE_MUTEX(flow_cache_cpu_sem); -static unsigned long flow_cache_cpu_map; +static cpumask_t flow_cache_cpu_map; static unsigned int flow_cache_cpu_count; static void flow_cache_new_hashrnd(unsigned long arg) -- Thanks Jack Steiner (steiner@sgi.com) 651-683-5302 Principal Engineer SGI - Silicon Graphics, Inc. From davem@pizda.ninka.net Fri Nov 7 16:17:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 07 Nov 2003 16:18:02 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA80Hk25002532 for ; Fri, 7 Nov 2003 16:17:47 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA05757; Fri, 7 Nov 2003 16:12:12 -0800 Date: Fri, 7 Nov 2003 16:12:12 -0800 From: "David S. Miller" To: Jack Steiner Cc: netdev@oss.sgi.com Subject: Re: FW: [PATCH] - Incorrect cpumask definition in net/core/flow.c Message-Id: <20031107161212.5521629b.davem@redhat.com> In-Reply-To: <20031107223729.GA20687@sgi.com> References: <20031107223729.GA20687@sgi.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1270 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 7 Nov 2003 16:37:29 -0600 Jack Steiner wrote: > The field "cpumap" is defined as a "unsigned long". It > should be a "cpumask_t". You can't just do this, that's more broken than the original code. You have to _ALSO_ change all of the accesses to these objects to use the cpumask interfaces. From herbert@gondor.apana.org.au Fri Nov 7 18:58:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 07 Nov 2003 18:59:05 -0800 (PST) Received: from arnor.me.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA82wl25006767 for ; Fri, 7 Nov 2003 18:58:49 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.me.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1AIJIV-0005Wt-00; Sat, 08 Nov 2003 13:57:59 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1AIJIT-0002q9-00; Sat, 08 Nov 2003 13:57:57 +1100 From: Herbert Xu To: steiner@sgi.com (Jack Steiner), davem@redhat.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] - Incorrect cpumask definition in net/core/flow.c Organization: Core In-Reply-To: <20031107210848.GA10774@sgi.com> X-Newsgroups: apana.lists.os.linux.kernel User-Agent: tin/1.7.2-20031002 ("Berneray") (UNIX) (Linux/2.4.22-1-686-smp (i686)) Message-Id: Date: Sat, 08 Nov 2003 13:57:57 +1100 X-archive-position: 1271 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Jack Steiner wrote: > This fixes a problem in net/core/flow.c. > > The field "cpumap" is defined as a "unsigned long". It > should be a "cpumask_t". Thanks. Here is a patch that changes the operations on the maps as well for consistency. -- Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- Index: kernel-source-2.5/net/core/flow.c =================================================================== RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/net/core/flow.c,v retrieving revision 1.8 diff -u -r1.8 flow.c --- kernel-source-2.5/net/core/flow.c 11 Oct 2003 06:29:28 -0000 1.8 +++ kernel-source-2.5/net/core/flow.c 8 Nov 2003 02:54:01 -0000 @@ -19,6 +19,7 @@ #include #include #include +#include #include #include #include @@ -65,7 +66,7 @@ struct flow_flush_info { atomic_t cpuleft; - unsigned long cpumap; + cpumask_t cpumap; struct completion completion; }; static DEFINE_PER_CPU(struct tasklet_struct, flow_flush_tasklets) = { NULL }; @@ -73,7 +74,7 @@ #define flow_flush_tasklet(cpu) (&per_cpu(flow_flush_tasklets, cpu)) static DECLARE_MUTEX(flow_cache_cpu_sem); -static unsigned long flow_cache_cpu_map; +static cpumask_t flow_cache_cpu_map; static unsigned int flow_cache_cpu_count; static void flow_cache_new_hashrnd(unsigned long arg) @@ -81,7 +82,7 @@ int i; for (i = 0; i < NR_CPUS; i++) - if (test_bit(i, &flow_cache_cpu_map)) + if (cpu_isset(i, flow_cache_cpu_map)) flow_hash_rnd_recalc(i) = 1; flow_hash_rnd_timer.expires = jiffies + FLOW_HASH_RND_PERIOD; @@ -178,7 +179,7 @@ cpu = smp_processor_id(); fle = NULL; - if (!test_bit(cpu, &flow_cache_cpu_map)) + if (!cpu_isset(cpu, flow_cache_cpu_map)) goto nocache; if (flow_hash_rnd_recalc(cpu)) @@ -277,7 +278,7 @@ struct tasklet_struct *tasklet; cpu = smp_processor_id(); - if (!test_bit(cpu, &info->cpumap)) + if (!cpu_isset(cpu, info->cpumap)) return; tasklet = flow_flush_tasklet(cpu); @@ -301,7 +302,7 @@ local_bh_disable(); smp_call_function(flow_cache_flush_per_cpu, &info, 1, 0); - if (test_bit(smp_processor_id(), &info.cpumap)) + if (cpu_isset(smp_processor_id(), info.cpumap)) flow_cache_flush_tasklet((unsigned long)&info); local_bh_enable(); @@ -341,7 +342,7 @@ static int __devinit flow_cache_cpu_online(int cpu) { down(&flow_cache_cpu_sem); - set_bit(cpu, &flow_cache_cpu_map); + cpu_set(cpu, flow_cache_cpu_map); flow_cache_cpu_count++; up(&flow_cache_cpu_sem); From garzik@gtf.org Sat Nov 8 09:56:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 08 Nov 2003 09:56:23 -0800 (PST) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA8Hu025027566 for ; Sat, 8 Nov 2003 09:56:00 -0800 Received: by havoc.gtf.org (Postfix, from userid 500) id 5B3E766AB; Sat, 8 Nov 2003 12:27:48 -0500 (EST) Date: Sat, 8 Nov 2003 12:27:48 -0500 From: Jeff Garzik To: torvalds@osdl.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [BK PATCHES] net driver fixes Message-ID: <20031108172748.GA8186@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 1272 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Linus, please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.5 This will update the following files: drivers/net/b44.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++-- drivers/net/pcnet32.c | 4 +++ 2 files changed, 58 insertions(+), 2 deletions(-) through these ChangeSets: (03/11/08 1.1416) [netdrvr pcnet32] add missing pci_dma_sync_single a patch for the pcnet32.c driver which adds a missing call to pci_dma_sync_single. If a received packet is smaller than rx_copybreak the pcnet driver will recycle the receive buffer which requires calling pci_dma_sync_single. Patch is against 2.6 but I it's also needed in 2.4. Without that call the processor might still have old stale data in the data cache when the processor accesses the recycled buffer. (03/11/08 1.1415) [netdrvr b44] Fix irq enable/disable; fix oops due to lack of SET_NETDEV_DEV() call Also, add suspend/resume functions. From rddunlap@osdl.org Sat Nov 8 16:07:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 08 Nov 2003 16:07:16 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA907325001009 for ; Sat, 8 Nov 2003 16:07:03 -0800 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id hA906vC19837; Sat, 8 Nov 2003 16:06:57 -0800 Date: Sat, 8 Nov 2003 16:04:41 -0800 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: saw@saw.sw.com.sg, akpm@osdl.org Subject: [PATCH] enabling netdev boot options (2.6.0-t9) Message-Id: <20031108160441.3a0a5505.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1274 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev description: enable eepro100 and 3c59x drivers to recognize 'netdev=' boot options: use dev_alloc_name() to assign an interface name, then use netdev_boot_setup_check() to check for boot options for that interface (name); maintainer: Andrey V. Savochkin (saw@saw.sw.com.sg); Andrew Morton (akpm@osdl.org) et al product_versions: Linux 2.6.0-test9 diffstat:= drivers/net/3c59x.c | 15 ++++++++++++++- drivers/net/eepro100.c | 12 +++++++----- 2 files changed, 21 insertions(+), 6 deletions(-) diff -Naurp ./drivers/net/eepro100.c~netdev ./drivers/net/eepro100.c --- ./drivers/net/eepro100.c~netdev 2003-10-25 11:44:01.000000000 -0700 +++ ./drivers/net/eepro100.c 2003-11-08 15:32:36.000000000 -0800 @@ -681,17 +681,19 @@ static int __devinit speedo_found1(struc SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); - if (dev->mem_start > 0) + rtnl_lock(); + + if (dev_alloc_name(dev, dev->name) < 0) + goto err_free_unlock; + + if (netdev_boot_setup_check(dev) && dev->mem_start > 0) { option = dev->mem_start; + } else if (card_idx >= 0 && options[card_idx] >= 0) option = options[card_idx]; else option = 0; - rtnl_lock(); - if (dev_alloc_name(dev, dev->name) < 0) - goto err_free_unlock; - /* Read the station address EEPROM before doing the reset. Nominally his should even be done before accepting the device, but then we wouldn't have a device name with which to report the error. diff -Naurp ./drivers/net/3c59x.c~netdev ./drivers/net/3c59x.c --- ./drivers/net/3c59x.c~netdev 2003-10-25 11:42:42.000000000 -0700 +++ ./drivers/net/3c59x.c 2003-11-08 15:29:50.000000000 -0800 @@ -259,6 +259,7 @@ static int vortex_debug = 1; #include #include #include +#include #include #include #include @@ -1110,6 +1111,16 @@ static int __devinit vortex_probe1(struc SET_NETDEV_DEV(dev, gendev); vp = dev->priv; + rtnl_lock(); + + retval = dev_alloc_name(dev, dev->name); + if (retval < 0) + goto err_free_unlock; + + rtnl_unlock(); + + netdev_boot_setup_check(dev); + option = global_options; /* The lower four bits are the media type. */ @@ -1468,8 +1479,10 @@ free_ring: free_region: if (vp->must_free_region) release_region(ioaddr, vci->io_size); - free_netdev(dev); +err_free_unlock: printk(KERN_ERR PFX "vortex_probe1 fails. Returns %d\n", retval); + rtnl_unlock(); + free_netdev(dev); out: return retval; } From rddunlap@osdl.org Sat Nov 8 16:06:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 08 Nov 2003 16:06:56 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA906f25000986 for ; Sat, 8 Nov 2003 16:06:43 -0800 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id hA906WC19811; Sat, 8 Nov 2003 16:06:33 -0800 Date: Sat, 8 Nov 2003 16:04:16 -0800 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: saw@saw.sw.com.sg, akpm@osdl.org Subject: [PATCH/RFC] enabling netdev boot options Message-Id: <20031108160416.236ec29d.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1273 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev I have modified 3c59x.c (for 2.4.22 and 2.6.0-test9) and eepro100 (for 2.6.0-test9 only) to check for netdev= boot options. I have verified that this change works (on 2.6.0-test9) when using an Intel PRO/100 NIC. netdev_boot_setup_check() needs to know the interface name to check for boot options, so I added calls to dev_alloc_name() so that the interface name would be assigned before calling netdev_boot_setup_check(). Other options include wedging some function so that netdev_boot_setup_check() is called automatically, but it needs to be done very soon after dev_alloc_name() so that dev->{irq, base_addr, mem_start, mem_end} are not clobbered. (Here are some other options that I've considered.) Option 3: with an API change, it could pass back a struct ifmap instead of clobbering the dev-> fields. Option 4: use something other than interface name to save and lookup netdev boot options. Possibly a unique identifier, like a MAC address. Option 5: I expect that the long-term solution is to use sysfs (2.6.x or 2.7). Any comments/preferences about that? 3c59x patch for 2.4.22 is below. 2.6.0-test9 patch follows in next email. -- ~Randy description: enable 3c59x driver to recognize 'netdev=' boot options changelog: use dev_alloc_name() to assign an interface name, then use netdev_boot_setup_check() to check for boot options for that interface (name); maintainer: Andrew Morton et al product_versions: Linux 2.4.22 patch_name: 3c59x-boot-setup.patch patch_version: 2003-11-08.15:22:30 diffstat:= drivers/net/3c59x.c | 15 ++++++++++++++- 1 files changed, 14 insertions(+), 1 deletion(-) diff -Naurp ./drivers/net/3c59x.c~boot-setup ./drivers/net/3c59x.c --- ./drivers/net/3c59x.c~boot-setup 2003-08-25 04:44:42.000000000 -0700 +++ ./drivers/net/3c59x.c 2003-11-08 15:20:15.000000000 -0800 @@ -250,6 +250,7 @@ static int vortex_debug = 1; #include #include #include +#include #include #include #include @@ -1017,6 +1018,16 @@ static int __devinit vortex_probe1(struc SET_MODULE_OWNER(dev); vp = dev->priv; + rtnl_lock(); + + retval = dev_alloc_name(dev, dev->name); + if (retval < 0) + goto err_free_unlock; + + rtnl_unlock(); + + netdev_boot_setup_check(dev); + /* The lower four bits are the media type. */ if (dev->mem_start) { /* @@ -1351,8 +1362,10 @@ free_ring: free_region: if (vp->must_free_region) release_region(ioaddr, vci->io_size); - kfree (dev); +err_free_unlock: printk(KERN_ERR PFX "vortex_probe1 fails. Returns %d\n", retval); + rtnl_unlock(); + kfree (dev); out: return retval; } From akpm@osdl.org Sat Nov 8 16:19:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 08 Nov 2003 16:19:33 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA90JK25004494 for ; Sat, 8 Nov 2003 16:19:20 -0800 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id hA90JDC21337; Sat, 8 Nov 2003 16:19:13 -0800 Date: Sat, 8 Nov 2003 16:22:48 -0800 From: Andrew Morton To: "Randy.Dunlap" Cc: netdev@oss.sgi.com, saw@saw.sw.com.sg Subject: Re: [PATCH/RFC] enabling netdev boot options Message-Id: <20031108162248.5846ab46.akpm@osdl.org> In-Reply-To: <20031108160416.236ec29d.rddunlap@osdl.org> References: <20031108160416.236ec29d.rddunlap@osdl.org> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1275 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev "Randy.Dunlap" wrote: > > > I have modified 3c59x.c (for 2.4.22 and 2.6.0-test9) and eepro100 > (for 2.6.0-test9 only) to check for netdev= boot options. A worthy project, thanks. > + rtnl_lock(); > + > + retval = dev_alloc_name(dev, dev->name); > + if (retval < 0) > + goto err_free_unlock; > + > + rtnl_unlock(); It would be better to move this locking into the core net layer. Call dev_alloc_name_which_takes_rtnl_lock() here ;) > + > + netdev_boot_setup_check(dev); > + > /* The lower four bits are the media type. */ > if (dev->mem_start) { > /* > @@ -1351,8 +1362,10 @@ free_ring: > free_region: > if (vp->must_free_region) > release_region(ioaddr, vci->io_size); > - kfree (dev); > +err_free_unlock: > printk(KERN_ERR PFX "vortex_probe1 fails. Returns %d\n", retval); > + rtnl_unlock(); > + kfree (dev); > out: > return retval; > } This causes an rtnl_unlock() imbalance if vortex_probe1() takes the `goto free_region' path, does it not?? From rddunlap@osdl.org Sat Nov 8 17:06:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 08 Nov 2003 17:06:18 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA916425005163 for ; Sat, 8 Nov 2003 17:06:04 -0800 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id hA915wC27353; Sat, 8 Nov 2003 17:05:58 -0800 Date: Sat, 8 Nov 2003 17:03:42 -0800 From: "Randy.Dunlap" To: Andrew Morton Cc: netdev@oss.sgi.com, saw@saw.sw.com.sg Subject: Re: [PATCH/RFC] enabling netdev boot options Message-Id: <20031108170342.78548c86.rddunlap@osdl.org> In-Reply-To: <20031108162248.5846ab46.akpm@osdl.org> References: <20031108160416.236ec29d.rddunlap@osdl.org> <20031108162248.5846ab46.akpm@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1276 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev On Sat, 8 Nov 2003 16:22:48 -0800 Andrew Morton wrote: | "Randy.Dunlap" wrote: | > | > | > I have modified 3c59x.c (for 2.4.22 and 2.6.0-test9) and eepro100 | > (for 2.6.0-test9 only) to check for netdev= boot options. | | A worthy project, thanks. | | > + rtnl_lock(); | > + | > + retval = dev_alloc_name(dev, dev->name); | > + if (retval < 0) | > + goto err_free_unlock; | > + | > + rtnl_unlock(); | | It would be better to move this locking into the core net layer. | Call dev_alloc_name_which_takes_rtnl_lock() here ;) Makes sense, but I'm wary of some drivers which do rtnl_lock() early and hold it for long times (like eepro100). Methinks that it shouldn't do that, but that's a different patch. | > @@ -1351,8 +1362,10 @@ free_ring: | > free_region: | > if (vp->must_free_region) | > release_region(ioaddr, vci->io_size); | > - kfree (dev); | > +err_free_unlock: | > printk(KERN_ERR PFX "vortex_probe1 fails. Returns %d\n", retval); | > + rtnl_unlock(); | > + kfree (dev); | > out: | > return retval; | > } | | This causes an rtnl_unlock() imbalance if vortex_probe1() takes the | `goto free_region' path, does it not?? I'll check that again. Might be right. -- ~Randy From rddunlap@osdl.org Sat Nov 8 18:53:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 08 Nov 2003 18:54:14 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA92rk25006181 for ; Sat, 8 Nov 2003 18:53:48 -0800 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id hA92reC06532; Sat, 8 Nov 2003 18:53:40 -0800 Date: Sat, 8 Nov 2003 18:51:23 -0800 From: "Randy.Dunlap" To: Andrew Morton Cc: netdev@oss.sgi.com, saw@saw.sw.com.sg Subject: Re: [PATCH/RFC] enabling netdev boot options Message-Id: <20031108185123.2fb8f1ac.rddunlap@osdl.org> In-Reply-To: <20031108162248.5846ab46.akpm@osdl.org> References: <20031108160416.236ec29d.rddunlap@osdl.org> <20031108162248.5846ab46.akpm@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1277 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev On Sat, 8 Nov 2003 16:22:48 -0800 Andrew Morton wrote: | "Randy.Dunlap" wrote: | > | > | > I have modified 3c59x.c (for 2.4.22 and 2.6.0-test9) and eepro100 | > (for 2.6.0-test9 only) to check for netdev= boot options. | | A worthy project, thanks. | | > + rtnl_lock(); | > + | > + retval = dev_alloc_name(dev, dev->name); | > + if (retval < 0) | > + goto err_free_unlock; | > + | > + rtnl_unlock(); | | It would be better to move this locking into the core net layer. | Call dev_alloc_name_which_takes_rtnl_lock() here ;) [snip] | This causes an rtnl_unlock() imbalance if vortex_probe1() takes the | `goto free_region' path, does it not?? Yes, that's right. Updated patch is below (for 2.4.22), still using rtnl_lock() and rtnl_unlock(). I'll make a locking version of dev_alloc_name() next [for 2.6], as well as 2.6.0-test9 patch updates. I'll make a locking version of dev_alloc_name() for 2.4.2x if it's wanted. Thanks. -- ~Randy description: enable 3c59x driver to recognize 'netdev=' boot options changelog: use dev_alloc_name() to assign an interface name, then use netdev_boot_setup_check() to check for boot options for that interface (name); maintainer: Andrew Morton et al product_versions: Linux 2.4.22 diffstat:= drivers/net/3c59x.c | 13 +++++++++++++ 1 files changed, 13 insertions(+) diff -Naurp ./drivers/net/3c59x.c~boot-setup ./drivers/net/3c59x.c --- ./drivers/net/3c59x.c~boot-setup 2003-08-25 04:44:42.000000000 -0700 +++ ./drivers/net/3c59x.c 2003-11-08 18:42:01.000000000 -0800 @@ -250,6 +250,7 @@ static int vortex_debug = 1; #include #include #include +#include #include #include #include @@ -1017,6 +1018,18 @@ static int __devinit vortex_probe1(struc SET_MODULE_OWNER(dev); vp = dev->priv; + rtnl_lock(); + + retval = dev_alloc_name(dev, dev->name); + if (retval < 0) { + rtnl_unlock(); + goto free_region; + } + + rtnl_unlock(); + + netdev_boot_setup_check(dev); + /* The lower four bits are the media type. */ if (dev->mem_start) { /* From rddunlap@osdl.org Sat Nov 8 20:46:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 08 Nov 2003 20:46:51 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA94kT25010364 for ; Sat, 8 Nov 2003 20:46:33 -0800 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id hA94kNC18448; Sat, 8 Nov 2003 20:46:23 -0800 Date: Sat, 8 Nov 2003 20:44:06 -0800 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: saw@saw.sw.com.sg, akpm@osdl.org Subject: Re: [PATCH] enabling netdev boot options (2.6.0-t9) Message-Id: <20031108204406.5dbbdc87.rddunlap@osdl.org> In-Reply-To: <20031108160441.3a0a5505.rddunlap@osdl.org> References: <20031108160441.3a0a5505.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1278 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Here's an update for 2.6.0-test9. This update adds dev_alloc_name_lock(), which takes and releases the rtnl lock to call dev_alloc_name(), so that the caller doesn't have to do that. More comments? Thanks, -- ~Randy description: enable eepro100 and 3c59x drivers to recognize 'netdev=' boot options: use dev_alloc_name() to assign an interface name if rtnl lock is already held (eepro100); use [new] dev_alloc_name_lock() to assign interface name if required lock is not already held; then use netdev_boot_setup_check() to check for boot options for that interface (name); add dev_alloc_name_lock() to net/core/dev.c; maintainer: Andrey V. Savochkin (saw@saw.sw.com.sg); Andrew Morton (akpm@osdl.org) et al product_versions: Linux 2.6.0-test9 diffstat:= drivers/net/3c59x.c | 6 ++++++ drivers/net/eepro100.c | 12 +++++++----- include/linux/netdevice.h | 1 + net/core/dev.c | 23 +++++++++++++++++++++++ 4 files changed, 37 insertions(+), 5 deletions(-) diff -Naurp ./drivers/net/eepro100.c~netdev ./drivers/net/eepro100.c --- ./drivers/net/eepro100.c~netdev 2003-10-25 11:44:01.000000000 -0700 +++ ./drivers/net/eepro100.c 2003-11-08 20:05:38.000000000 -0800 @@ -681,17 +681,19 @@ static int __devinit speedo_found1(struc SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); - if (dev->mem_start > 0) + rtnl_lock(); + + if (dev_alloc_name(dev, dev->name) < 0) + goto err_free_unlock; + + if (netdev_boot_setup_check(dev) && dev->mem_start > 0) { option = dev->mem_start; + } else if (card_idx >= 0 && options[card_idx] >= 0) option = options[card_idx]; else option = 0; - rtnl_lock(); - if (dev_alloc_name(dev, dev->name) < 0) - goto err_free_unlock; - /* Read the station address EEPROM before doing the reset. Nominally his should even be done before accepting the device, but then we wouldn't have a device name with which to report the error. diff -Naurp ./drivers/net/3c59x.c~netdev ./drivers/net/3c59x.c --- ./drivers/net/3c59x.c~netdev 2003-10-25 11:42:42.000000000 -0700 +++ ./drivers/net/3c59x.c 2003-11-08 20:13:39.000000000 -0800 @@ -1110,6 +1110,12 @@ static int __devinit vortex_probe1(struc SET_NETDEV_DEV(dev, gendev); vp = dev->priv; + retval = dev_alloc_name_lock(dev, dev->name); + if (retval < 0) + goto free_region; + + netdev_boot_setup_check(dev); + option = global_options; /* The lower four bits are the media type. */ diff -Naurp ./net/core/dev.c~netdev ./net/core/dev.c --- ./net/core/dev.c~netdev 2003-10-25 11:43:39.000000000 -0700 +++ ./net/core/dev.c 2003-11-08 20:15:00.000000000 -0800 @@ -635,6 +635,29 @@ int dev_alloc_name(struct net_device *de } /** + * dev_alloc_name_lock - allocate a name for a device, + * with required locking + * @dev: device + * @name: name format string + * + * Passed a format string - eg "lt%d" it will try and find a suitable + * id. Not efficient for many devices, not called a lot. + * This function takes the rtnl lock while allocating the name and + * adding the device in order to avoid duplicates. + * Returns the number of the unit assigned or a negative errno code. + */ + +int dev_alloc_name_lock(struct net_device *dev, const char *name) +{ + int ret; + + rtnl_lock(); + ret = dev_alloc_name(dev, name); + rtnl_unlock(); + return ret; +} + +/** * dev_alloc - allocate a network device and name * @name: name format string * @err: error return pointer diff -Naurp ./include/linux/netdevice.h~netdev ./include/linux/netdevice.h --- ./include/linux/netdevice.h~netdev 2003-10-25 11:44:45.000000000 -0700 +++ ./include/linux/netdevice.h 2003-11-08 20:01:33.000000000 -0800 @@ -518,6 +518,7 @@ static inline __deprecated struct net_de return __dev_alloc(name, err); } extern int dev_alloc_name(struct net_device *dev, const char *name); +extern int dev_alloc_name_lock(struct net_device *dev, const char *name); extern int dev_open(struct net_device *dev); extern int dev_close(struct net_device *dev); extern int dev_queue_xmit(struct sk_buff *skb); From torvalds@osdl.org Sat Nov 8 21:53:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 08 Nov 2003 21:54:07 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA95rn25011289 for ; Sat, 8 Nov 2003 21:53:50 -0800 Received: from localhost (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id hA95riC25706 for ; Sat, 8 Nov 2003 21:53:44 -0800 X-Received: from localhost (localhost.localdomain [127.0.0.1]) by home.osdl.org (8.12.10/8.12.10) with ESMTP id hA94ZXqR002010 for ; Sat, 8 Nov 2003 20:35:33 -0800 X-Received: from localhost.localdomain [127.0.0.1] by localhost with IMAP (fetchmail-6.2.0) for torvalds@localhost (single-drop); Sat, 08 Nov 2003 20:35:33 -0800 (PST) X-Received: from fire-1.osdl.org (air1.pdx.osdl.net [172.20.0.5]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id hA94XgC17622 for ; Sat, 8 Nov 2003 20:33:42 -0800 X-Received: from vger.kernel.org (vger.kernel.org [67.72.78.212]) by fire-1.osdl.org (8.12.8/8.12.8) with ESMTP id hA94Xf0e017266 for ; Sat, 8 Nov 2003 20:33:42 -0800 X-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262174AbTKIE2Y (ORCPT ); Sat, 8 Nov 2003 23:28:24 -0500 X-Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262176AbTKIE2Y (ORCPT ); Sat, 8 Nov 2003 23:28:24 -0500 X-Received: from cap175-219-202.pixi.net ([207.175.219.202]:39812 "EHLO beaucox.com") by vger.kernel.org with ESMTP id S262174AbTKIE2W (ORCPT ); Sat, 8 Nov 2003 23:28:22 -0500 X-Received: from 10.0.0.2 (10.0.0.2:33411) by cap175-219-202.pixi.net with [XMail 1.17 (Linux/Ix86) ESMTP Server] id for from ; Sat, 8 Nov 2003 18:21:16 -1000 From: "Beau E. Cox" Organization: BeauCox.com To: linux-kernel@vger.kernel.org Subject: PROBLEM: PATCH for 2.4.23-pre4 and up hang on one system Date: Sat, 8 Nov 2003 18:27:28 -1000 User-Agent: KMail/1.5.4 Cc: Marcelo Tosatti MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200311081341.38553.beau@beaucox.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-Scanned-By: MIMEDefang 2.36 ReSent-Date: Sat, 8 Nov 2003 21:53:22 -0800 (PST) ReSent-From: Linus Torvalds ReSent-To: netdev@oss.sgi.com ReSent-Subject: PROBLEM: PATCH for 2.4.23-pre4 and up hang on one system ReSent-Message-ID: X-archive-position: 1279 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: torvalds@osdl.org Precedence: bulk X-list: netdev submitted Sat Nov 8 13:08:55 HST 2003 by Beau E. Cox [1.] One line summary of the problem: Patch that fixes my problem: Starting with 2.4.23-pre4 my system hangs during startup and/or is generally unstable (see patch in [ X. ] below.) [2.] Full description of the problem/report: Origionally I had catagorized this problem with the startup sequence; the system always seemed to hang when squid was started before mysql, etc. Moving squid near the end of the startup process, I thought the problem was in hand. However, the system (pre9) proved unstable (would not stay up for longer than one day.) The problem exhibits itself with a solid 'hang'; no oops, no dumps, nada. [ 3. ] - [ 7. ] See previous posting; no hardware or configuration changes. [X.] Other notes, patches, fixes, workarounds: This patch to net/ipv4/netfilter/ip_nat_core.c fixed my problem in all 2.4.23 versions pre4 - pre9: --- linux-2.4.23-pre4/net/ipv4/netfilter/ip_nat_core.c 2003-11-08 03:01:59.000000000 -1000 +++ linux-2.4.23-pre3/net/ipv4/netfilter/ip_nat_core.c 2003-11-08 03:00:47.000000000 -1000 @@ -157,8 +157,8 @@ continue; } - if (!(mr->range[i].flags & IP_NAT_RANGE_PROTO_SPECIFIED) - || proto->in_range(&newtuple, IP_NAT_MANIP_SRC, + if ((mr->range[i].flags & IP_NAT_RANGE_PROTO_SPECIFIED) + && proto->in_range(&newtuple, IP_NAT_MANIP_SRC, &mr->range[i].min, &mr->range[i].max)) return 1; } It is simply a rollback of changes to ip_nat_core.c made in pre4. Since my patch is to ip_nat_core.c, I should mention that I use NAT via iptables. Here is an the relevant section if my iptables startup script: [...] # setup nat echo " applying nat rules" echo "" $iptables -F FORWARD $iptables -F -t nat $iptables -P FORWARD DROP $iptables -A FORWARD -i eth0 -j ACCEPT $iptables -A INPUT -i eth0 -j ACCEPT $iptables -A OUTPUT -o eth0 -j ACCEPT $iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT $iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth1 -j SNAT --to-source x.x.x.x [...] All the information I can think of relating to this problem is at: ftp://beaucox.com/pub/kernel/2.4.23-pre4-bug Please see the README file. ---------------------------WARNING-------------------------- I am NOT a kernel programmer. The patch above was arrived at by hit-or-miss. I REALLY don't know what I am doing (but my system works now!) ---------------------------WARNING-------------------------- Aloha => Beau; PS: Please let me know if you need more information. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From akpm@osdl.org Sat Nov 8 22:02:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 08 Nov 2003 22:03:02 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA962m25011706 for ; Sat, 8 Nov 2003 22:02:49 -0800 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id hA962hC26737; Sat, 8 Nov 2003 22:02:43 -0800 Date: Sat, 8 Nov 2003 22:06:21 -0800 From: Andrew Morton To: "Randy.Dunlap" Cc: netdev@oss.sgi.com, saw@saw.sw.com.sg Subject: Re: [PATCH] enabling netdev boot options (2.6.0-t9) Message-Id: <20031108220621.11d39feb.akpm@osdl.org> In-Reply-To: <20031108204406.5dbbdc87.rddunlap@osdl.org> References: <20031108160441.3a0a5505.rddunlap@osdl.org> <20031108204406.5dbbdc87.rddunlap@osdl.org> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1280 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev "Randy.Dunlap" wrote: > > +int dev_alloc_name_lock(struct net_device *dev, const char *name) You'll need to export this guy to modules. From davem@pizda.ninka.net Sat Nov 8 22:32:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 08 Nov 2003 22:32:50 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA96Wa25012283 for ; Sat, 8 Nov 2003 22:32:36 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id WAA23045; Sat, 8 Nov 2003 22:26:45 -0800 Date: Sat, 8 Nov 2003 22:26:45 -0800 From: "David S. Miller" To: Herbert Xu Cc: steiner@sgi.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] - Incorrect cpumask definition in net/core/flow.c Message-Id: <20031108222645.4e3d23f1.davem@redhat.com> In-Reply-To: References: <20031107210848.GA10774@sgi.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1281 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 08 Nov 2003 13:57:57 +1100 Herbert Xu wrote: > Here is a patch that changes the operations on the maps as well > for consistency. This is the correct patch, applied thanks. I have another patch that cleans up this stuff in a better albeit intrusive way from Rusty, but let's be safe for 2.6.0 From davem@pizda.ninka.net Sat Nov 8 22:36:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 08 Nov 2003 22:36:41 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA96aT25012658 for ; Sat, 8 Nov 2003 22:36:29 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id WAA23080; Sat, 8 Nov 2003 22:30:49 -0800 Date: Sat, 8 Nov 2003 22:30:49 -0800 From: "David S. Miller" To: Krishna Kumar Cc: netdev@oss.sgi.com, krkumar@us.ibm.com Subject: Re: [PATCH] Hang in downing interface with IPv6 PRIVACY Message-Id: <20031108223049.36651f8d.davem@redhat.com> In-Reply-To: References: <20031106115935.0cd56745.davem@redhat.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1282 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 7 Nov 2003 11:01:41 -0800 (PST) Krishna Kumar wrote: > While using PRIVACY extensions, I sometimes get a hang when I remove the > interface. But I can reproduce this every time using the test script at > the end of the mail (hang depends on the order of address deletion). ... > The bug is in ipv6_del_addr() where if a temp address is being deleted ... > Also, the code at the top of the routine is unnecessary, the same is being > done when the address is found a little later in that routine. Looks great, applied. Thanks. From rask@sygehus.dk Sun Nov 9 02:57:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 09 Nov 2003 02:57:59 -0800 (PST) Received: from 0x50a41c03.albnxx15.adsl-dhcp.tele.dk (0x50a41c03.albnxx15.adsl-dhcp.tele.dk [80.164.28.3]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA9Avi25019022 for ; Sun, 9 Nov 2003 02:57:45 -0800 Received: by 0x50a41c03.albnxx15.adsl-dhcp.tele.dk (Postfix, from userid 500) id 452891F439; Sun, 9 Nov 2003 11:55:36 +0100 (CET) Date: Sun, 9 Nov 2003 11:55:35 +0100 From: Rask Ingemann Lambertsen To: "Randy.Dunlap" Cc: netdev@oss.sgi.com, saw@saw.sw.com.sg, akpm@osdl.org Subject: Re: [PATCH] enabling netdev boot options (2.6.0-t9) Message-ID: <20031109115535.A1282@sygehus.dk> References: <20031108160441.3a0a5505.rddunlap@osdl.org> <20031108204406.5dbbdc87.rddunlap@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031108204406.5dbbdc87.rddunlap@osdl.org>; from rddunlap@osdl.org on Sat, Nov 08, 2003 at 08:44:06PM -0800 X-archive-position: 1283 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rask@sygehus.dk Precedence: bulk X-list: netdev On Sat, Nov 08, 2003 at 08:44:06PM -0800, Randy.Dunlap wrote: > > Here's an update for 2.6.0-test9. This update adds > dev_alloc_name_lock(), which takes and releases the rtnl lock > to call dev_alloc_name(), so that the caller doesn't have to do that. > > More comments? I don't like that name for the function. dev_alloc_name_lock() makes it natural to think that there is a matching dev_alloc_name_unlock() function which you should call afterwards. How about dev_alloc_name_locked() or dev_alloc_name_with_lock() instead? -- Regards, Rask Ingemann Lambertsen From rask@sygehus.dk Sun Nov 9 03:36:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 09 Nov 2003 03:37:03 -0800 (PST) Received: from 0x50a41c03.albnxx15.adsl-dhcp.tele.dk (0x50a41c03.albnxx15.adsl-dhcp.tele.dk [80.164.28.3]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA9Bag25019726 for ; Sun, 9 Nov 2003 03:36:45 -0800 Received: by 0x50a41c03.albnxx15.adsl-dhcp.tele.dk (Postfix, from userid 500) id 21F951F439; Sun, 9 Nov 2003 12:34:36 +0100 (CET) Date: Sun, 9 Nov 2003 12:34:35 +0100 From: Rask Ingemann Lambertsen To: Sven Schuster Cc: linux-net@vger.kernel.org, netdev Subject: Re: Linux <---> Unixware slow networking with e100 Message-ID: <20031109123435.B1282@sygehus.dk> References: <3FA9F8D5.9020601@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3FA9F8D5.9020601@gmx.de>; from schuster.sven@gmx.de on Thu, Nov 06, 2003 at 08:31:33AM +0100 X-archive-position: 1284 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rask@sygehus.dk Precedence: bulk X-list: netdev On Thu, Nov 06, 2003 at 08:31:33AM +0100, Sven Schuster wrote: > But when _receiving_ data from one of the unixware machines, we > just get a few kB/s, max. about 100 kB/s. When _sending_ data to > a unixware machine, the transfer rate is fine too. Are there any > known issues between linux and unixware (except the SCO thing > ;-) ) ?? Run tcpdump and see what the window sizes are when sending data from Unixware to Linux. -- Regards, Rask Ingemann Lambertsen From wsx@6com.sk Sun Nov 9 04:28:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 09 Nov 2003 04:29:18 -0800 (PST) Received: from mail.6com.sk (cement.ksp.edi.fmph.uniba.sk [158.195.16.151]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA9CSt25028456 for ; Sun, 9 Nov 2003 04:28:56 -0800 Received: by mail.6com.sk (Postfix, from userid 501) id BE5374C00083; Sun, 9 Nov 2003 07:28:44 -0500 (EST) Date: Sun, 9 Nov 2003 13:28:44 +0100 From: Jan Oravec To: netdev@oss.sgi.com, davem@redhat.com, yoshfuji@linux-ipv6.org Subject: IPv6/sparc64: icmp port unreachable corruption Message-ID: <20031109122844.GA14241@wsx.ksp.sk> Reply-To: Jan Oravec Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: UNIX X-archive-position: 1285 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jan.oravec@6com.sk Precedence: bulk X-list: netdev Hello, I have found the following problem with 2.6.0-test9-bk13 on sparc64: We do traceroute6 to 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 (IP of that sparc64). We get the following corrupted answer: 13:17:47.191547 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 > 3ffe:80ee:a:0:201:3ff:fed5:bd1e: [|icmp6] (len 72, hlim 62) 0x0000 6000 0000 0048 3a3e 3ffe 80ee 03bd 0000 ....H:>?....... 0x0010 0a00 20ff fec7 a192 3ffe 80ee 000a 0000 ........?....... 0x0020 0201 03ff fed5 bd1e 0104 aa7c 0000 0000 ...........|.... 0x0030 0000 0064 0000 0000 0100 0000 0100 0000 ...d............ 0x0040 aaaa aaaa aaaa aaaa 9680 c00b c622 7fec .............".. 0x0050 aaaa aaaa aaaa aaaa 9680 c00b c622 7ffc .............".. 0x0060 aaaa aaaa 0000 0000 8a10 2000 04c2 8049 ...............I When doing exactly same to x86 box (with 2.6.0-test7-bk7 running), we get the correct answer: 13:17:31.140230 3ffe:80ee:1:0:204:76ff:fe97:d69a > 3ffe:80ee:a:0:201:3ff:fed5:bd1e: icmp6: 3ffe:80ee:1:0:204:76ff:fe97:d69a udp port 33434 unreachable (len 72, hlim 63) 0x0000 6000 0000 0048 3a3f 3ffe 80ee 0001 0000 ....H:??....... 0x0010 0204 76ff fe97 d69a 3ffe 80ee 000a 0000 ..v.....?....... 0x0020 0201 03ff fed5 bd1e 0104 fb79 0000 0000 ...........y.... 0x0030 6000 0000 0018 1101 3ffe 80ee 000a 0000 .......?....... 0x0040 0201 03ff fed5 bd1e 3ffe 80ee 0001 0000 ........?....... 0x0050 0204 76ff fe97 d69a 8018 829a 0018 0c82 ..v............. 0x0060 0000 1df3 0000 0005 5b30 ae3f 3512 0200 ........[0.?5... Jan From wsx@6com.sk Sun Nov 9 05:26:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 09 Nov 2003 05:26:18 -0800 (PST) Received: from mail.6com.sk (cement.ksp.edi.fmph.uniba.sk [158.195.16.151]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA9DPw25029182 for ; Sun, 9 Nov 2003 05:26:00 -0800 Received: by mail.6com.sk (Postfix, from userid 501) id 37F904C00083; Sun, 9 Nov 2003 08:25:53 -0500 (EST) Date: Sun, 9 Nov 2003 14:25:53 +0100 From: Jan Oravec To: netdev@oss.sgi.com, davem@redhat.com, yoshfuji@linux-ipv6.org Subject: Re: IPv6/sparc64: icmp port unreachable corruption Message-ID: <20031109132552.GA17096@wsx.ksp.sk> Reply-To: Jan Oravec References: <20031109122844.GA14241@wsx.ksp.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031109122844.GA14241@wsx.ksp.sk> User-Agent: Mutt/1.4.1i X-Operating-System: UNIX X-archive-position: 1286 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jan.oravec@6com.sk Precedence: bulk X-list: netdev This may be related to the problem (on sparc64): # traceroute6 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 traceroute to 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 (3ffe:80ee:3bd:0:a00:20ff:fec7:a192) from ::1, 30 hops max, 24 byte packets Bus error # traceroute6 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 -s 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 traceroute to 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 (3ffe:80ee:3bd:0:a00:20ff:fec7:a192) from 3ffe:80ee:3bd:0:a00:20ff:fec7:a192, 30 hops max, 24 byte packets Bus error # traceroute6 www.kame.net traceroute to orange.kame.net (2001:200:0:8002:203:47ff:fea5:3085) from 3ffe:80ee:3bd:0:a00:20ff:fec7:a192, 30 hops max, 24 byte packets 1 skbra-00-01.pop.xs26.net (3ffe:80ee:3bd:0:a00:20ff:fec9:3aad) 0.953 ms 0.305 ms 0.341 ms ... The following lines are appearing in dmesg: raw v6 hw csum failure. All of this worked fine in 2.4.22-pre6. The common problem of 2.4 and 2.6 is with IPv4 traceroute, but it is probably because of buggy 64-bit traceroute, because it worked fine in 32-bit userspace: # traceroute www.google.com traceroute to www.google.akadns.net (216.239.57.99), 30 hops max, 52 byte packets Bus error On Sun, Nov 09, 2003 at 01:28:44PM +0100, Jan Oravec wrote: > Hello, > > > I have found the following problem with 2.6.0-test9-bk13 on sparc64: > > We do traceroute6 to 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 (IP of that > sparc64). We get the following corrupted answer: > > 13:17:47.191547 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 > 3ffe:80ee:a:0:201:3ff:fed5:bd1e: [|icmp6] (len 72, hlim 62) > 0x0000 6000 0000 0048 3a3e 3ffe 80ee 03bd 0000 ....H:>?....... > 0x0010 0a00 20ff fec7 a192 3ffe 80ee 000a 0000 ........?....... > 0x0020 0201 03ff fed5 bd1e 0104 aa7c 0000 0000 ...........|.... > 0x0030 0000 0064 0000 0000 0100 0000 0100 0000 ...d............ > 0x0040 aaaa aaaa aaaa aaaa 9680 c00b c622 7fec .............".. > 0x0050 aaaa aaaa aaaa aaaa 9680 c00b c622 7ffc .............".. > 0x0060 aaaa aaaa 0000 0000 8a10 2000 04c2 8049 ...............I > > > When doing exactly same to x86 box (with 2.6.0-test7-bk7 running), we get > the correct answer: > > 13:17:31.140230 3ffe:80ee:1:0:204:76ff:fe97:d69a > 3ffe:80ee:a:0:201:3ff:fed5:bd1e: icmp6: 3ffe:80ee:1:0:204:76ff:fe97:d69a udp port 33434 unreachable (len 72, hlim 63) > 0x0000 6000 0000 0048 3a3f 3ffe 80ee 0001 0000 ....H:??....... > 0x0010 0204 76ff fe97 d69a 3ffe 80ee 000a 0000 ..v.....?....... > 0x0020 0201 03ff fed5 bd1e 0104 fb79 0000 0000 ...........y.... > 0x0030 6000 0000 0018 1101 3ffe 80ee 000a 0000 .......?....... > 0x0040 0201 03ff fed5 bd1e 3ffe 80ee 0001 0000 ........?....... > 0x0050 0204 76ff fe97 d69a 8018 829a 0018 0c82 ..v............. > 0x0060 0000 1df3 0000 0005 5b30 ae3f 3512 0200 ........[0.?5... > > > Jan > From wsx@6com.sk Sun Nov 9 05:39:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 09 Nov 2003 05:40:08 -0800 (PST) Received: from mail.6com.sk (cement.ksp.edi.fmph.uniba.sk [158.195.16.151]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA9Ddj25029583 for ; Sun, 9 Nov 2003 05:39:50 -0800 Received: by mail.6com.sk (Postfix, from userid 501) id 0445F4C00083; Sun, 9 Nov 2003 08:39:39 -0500 (EST) Date: Sun, 9 Nov 2003 14:39:39 +0100 From: Jan Oravec To: netdev@oss.sgi.com, davem@redhat.com, yoshfuji@linux-ipv6.org Subject: Re: IPv6/sparc64: icmp port unreachable corruption Message-ID: <20031109133939.GA17333@wsx.ksp.sk> Reply-To: Jan Oravec References: <20031109122844.GA14241@wsx.ksp.sk> <20031109132552.GA17096@wsx.ksp.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031109132552.GA17096@wsx.ksp.sk> User-Agent: Mutt/1.4.1i X-Operating-System: UNIX X-archive-position: 1287 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jan.oravec@6com.sk Precedence: bulk X-list: netdev And another observation is that on 2.6.0-test9-bk4 on Opteron x86_64 when I do: # traceroute6 ::1 The kernel crashs. I will have kernel OOPS output tommorow (the box is located in office) On Sun, Nov 09, 2003 at 02:25:53PM +0100, Jan Oravec wrote: > This may be related to the problem (on sparc64): > > # traceroute6 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 > traceroute to 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 (3ffe:80ee:3bd:0:a00:20ff:fec7:a192) from ::1, 30 hops max, 24 byte packets > Bus error > > # traceroute6 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 -s 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 > traceroute to 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 (3ffe:80ee:3bd:0:a00:20ff:fec7:a192) from 3ffe:80ee:3bd:0:a00:20ff:fec7:a192, 30 hops max, 24 byte packets > Bus error > > # traceroute6 www.kame.net > traceroute to orange.kame.net (2001:200:0:8002:203:47ff:fea5:3085) from 3ffe:80ee:3bd:0:a00:20ff:fec7:a192, 30 hops max, 24 byte packets > 1 skbra-00-01.pop.xs26.net (3ffe:80ee:3bd:0:a00:20ff:fec9:3aad) 0.953 ms 0.305 ms 0.341 ms > ... > > The following lines are appearing in dmesg: > raw v6 hw csum failure. > > All of this worked fine in 2.4.22-pre6. > > > The common problem of 2.4 and 2.6 is with IPv4 traceroute, but it is > probably because of buggy 64-bit traceroute, because it worked fine in > 32-bit userspace: > > # traceroute www.google.com > traceroute to www.google.akadns.net (216.239.57.99), 30 hops max, 52 byte packets > Bus error > > > > On Sun, Nov 09, 2003 at 01:28:44PM +0100, Jan Oravec wrote: > > Hello, > > > > > > I have found the following problem with 2.6.0-test9-bk13 on sparc64: > > > > We do traceroute6 to 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 (IP of that > > sparc64). We get the following corrupted answer: > > > > 13:17:47.191547 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 > 3ffe:80ee:a:0:201:3ff:fed5:bd1e: [|icmp6] (len 72, hlim 62) > > 0x0000 6000 0000 0048 3a3e 3ffe 80ee 03bd 0000 ....H:>?....... > > 0x0010 0a00 20ff fec7 a192 3ffe 80ee 000a 0000 ........?....... > > 0x0020 0201 03ff fed5 bd1e 0104 aa7c 0000 0000 ...........|.... > > 0x0030 0000 0064 0000 0000 0100 0000 0100 0000 ...d............ > > 0x0040 aaaa aaaa aaaa aaaa 9680 c00b c622 7fec .............".. > > 0x0050 aaaa aaaa aaaa aaaa 9680 c00b c622 7ffc .............".. > > 0x0060 aaaa aaaa 0000 0000 8a10 2000 04c2 8049 ...............I > > > > > > When doing exactly same to x86 box (with 2.6.0-test7-bk7 running), we get > > the correct answer: > > > > 13:17:31.140230 3ffe:80ee:1:0:204:76ff:fe97:d69a > 3ffe:80ee:a:0:201:3ff:fed5:bd1e: icmp6: 3ffe:80ee:1:0:204:76ff:fe97:d69a udp port 33434 unreachable (len 72, hlim 63) > > 0x0000 6000 0000 0048 3a3f 3ffe 80ee 0001 0000 ....H:??....... > > 0x0010 0204 76ff fe97 d69a 3ffe 80ee 000a 0000 ..v.....?....... > > 0x0020 0201 03ff fed5 bd1e 0104 fb79 0000 0000 ...........y.... > > 0x0030 6000 0000 0018 1101 3ffe 80ee 000a 0000 .......?....... > > 0x0040 0201 03ff fed5 bd1e 3ffe 80ee 0001 0000 ........?....... > > 0x0050 0204 76ff fe97 d69a 8018 829a 0018 0c82 ..v............. > > 0x0060 0000 1df3 0000 0005 5b30 ae3f 3512 0200 ........[0.?5... > > > > > > Jan > > > From wsx@6com.sk Sun Nov 9 06:38:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 09 Nov 2003 06:38:27 -0800 (PST) Received: from mail.6com.sk (cement.ksp.edi.fmph.uniba.sk [158.195.16.151]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA9Ec325030397 for ; Sun, 9 Nov 2003 06:38:04 -0800 Received: by mail.6com.sk (Postfix, from userid 501) id 085434C00083; Sun, 9 Nov 2003 09:37:58 -0500 (EST) Date: Sun, 9 Nov 2003 15:37:57 +0100 From: Jan Oravec To: netdev@oss.sgi.com, davem@redhat.com, yoshfuji@linux-ipv6.org Subject: Re: IPv6/sparc64: icmp port unreachable corruption Message-ID: <20031109143757.GA17943@wsx.ksp.sk> Reply-To: Jan Oravec References: <20031109122844.GA14241@wsx.ksp.sk> <20031109132552.GA17096@wsx.ksp.sk> <20031109133939.GA17333@wsx.ksp.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031109133939.GA17333@wsx.ksp.sk> User-Agent: Mutt/1.4.1i X-Operating-System: UNIX X-archive-position: 1288 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jan.oravec@6com.sk Precedence: bulk X-list: netdev A colleague of mine has Opteron at home, he tried traceroute6 ::1 on 2.6.0-test9-bk4, here is the kernel output: RDX: 0000000000000048 RSI: 000001001ec06048 RDI: 000001011ec06218 RBP: 0000000000000048 R08: 0000000000000000 R09: 0000000000000000 R10: 000001001ea6d1c0 R11: 00000000000000dc R12: 0000000000000001 R13: 0000000000000000 R14: 000001001f95f740 R15: 000001001ec06048 FS: 0000002a958d2060(0000) GS:ffffffff804f4500(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000000101000 CR4: 00000000000006a0 Process traceroute6 (pid: 787, stackpage=1001eaf04e0) Stack: 0000000000000000 0000000000000000 0000000000000048 0000000000000048 000001001f95f740 0000000000000000 0000000000000048 ffffffff802e710f 0000000000000246 ffffffff8021f8d0 Call Trace:{csum_partial_copy_nocheck+15} {skb_copy_and_csum_bits+96} {icmpv6_getfrag+35} {ip6_append_data+1158} {icmpv6_getfrag+0} {icmpv6_send+1044} {updv6_rcv+647} {ip6_input_finish+429} {ip6_input_finish+0} {nf_hook_slow+227} {ip6_input_finish+0} {ip6_rcv_finish+0} {ip6_input+662} {nf_interate+94} {ip6_rcv_finish+0} {ip6_rcv_finish+31} {nf_hook_slow+227} {ip6_rcv_finish+0} {ipv6_rcv+503} {netif_receive_skb+394} {process_backlog+138} {net_rx_action+123} {do_softirq+123} {dev_queue_xmit+354} {neigh_resolve_output+322} {ip6_output_finish+0} {ip6_output_finish+163} {ip6_output_finish+0} {nf_hook_slow+227} {ip6_output_finish+0} {dst_output+0} {ip6_output2+540} {dst_output+17} {nf_hook_slow+227} {dst_output+0} {ip6_push_pending_frames+784} {ip6_append_data+1158} {udp_v6_push_pending_frames+319} {udpv6_sendmsg+1861} {inet_sendmsg+84} {sock_sendmsg+125} {find_get_page+13} {filemap_nopage+269} {do_no_page+813} {sockfd_lookup+32} {move_addr_to_kernel+39} {sys_sendto+233} {inet_setsockopt+18} {sys_setsockopt+147} {system_call+124} Code: c7 00 f2 ff ff ff eb d6 48 8b 44 24 08 c7 00 f2 ff ff ff eb RIP {csum_partial_copy_generic+349} RSP <000001001e6354c8> CR2: 0000000000000000 <0>Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing On Sun, Nov 09, 2003 at 02:39:39PM +0100, Jan Oravec wrote: > And another observation is that on 2.6.0-test9-bk4 on Opteron x86_64 when I > do: > > # traceroute6 ::1 > > The kernel crashs. > > I will have kernel OOPS output tommorow (the box is located in office) > > > > On Sun, Nov 09, 2003 at 02:25:53PM +0100, Jan Oravec wrote: > > This may be related to the problem (on sparc64): > > > > # traceroute6 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 > > traceroute to 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 (3ffe:80ee:3bd:0:a00:20ff:fec7:a192) from ::1, 30 hops max, 24 byte packets > > Bus error > > > > # traceroute6 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 -s 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 > > traceroute to 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 (3ffe:80ee:3bd:0:a00:20ff:fec7:a192) from 3ffe:80ee:3bd:0:a00:20ff:fec7:a192, 30 hops max, 24 byte packets > > Bus error > > > > # traceroute6 www.kame.net > > traceroute to orange.kame.net (2001:200:0:8002:203:47ff:fea5:3085) from 3ffe:80ee:3bd:0:a00:20ff:fec7:a192, 30 hops max, 24 byte packets > > 1 skbra-00-01.pop.xs26.net (3ffe:80ee:3bd:0:a00:20ff:fec9:3aad) 0.953 ms 0.305 ms 0.341 ms > > ... > > > > The following lines are appearing in dmesg: > > raw v6 hw csum failure. > > > > All of this worked fine in 2.4.22-pre6. > > > > > > The common problem of 2.4 and 2.6 is with IPv4 traceroute, but it is > > probably because of buggy 64-bit traceroute, because it worked fine in > > 32-bit userspace: > > > > # traceroute www.google.com > > traceroute to www.google.akadns.net (216.239.57.99), 30 hops max, 52 byte packets > > Bus error > > > > > > > > On Sun, Nov 09, 2003 at 01:28:44PM +0100, Jan Oravec wrote: > > > Hello, > > > > > > > > > I have found the following problem with 2.6.0-test9-bk13 on sparc64: > > > > > > We do traceroute6 to 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 (IP of that > > > sparc64). We get the following corrupted answer: > > > > > > 13:17:47.191547 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 > 3ffe:80ee:a:0:201:3ff:fed5:bd1e: [|icmp6] (len 72, hlim 62) > > > 0x0000 6000 0000 0048 3a3e 3ffe 80ee 03bd 0000 ....H:>?....... > > > 0x0010 0a00 20ff fec7 a192 3ffe 80ee 000a 0000 ........?....... > > > 0x0020 0201 03ff fed5 bd1e 0104 aa7c 0000 0000 ...........|.... > > > 0x0030 0000 0064 0000 0000 0100 0000 0100 0000 ...d............ > > > 0x0040 aaaa aaaa aaaa aaaa 9680 c00b c622 7fec .............".. > > > 0x0050 aaaa aaaa aaaa aaaa 9680 c00b c622 7ffc .............".. > > > 0x0060 aaaa aaaa 0000 0000 8a10 2000 04c2 8049 ...............I > > > > > > > > > When doing exactly same to x86 box (with 2.6.0-test7-bk7 running), we get > > > the correct answer: > > > > > > 13:17:31.140230 3ffe:80ee:1:0:204:76ff:fe97:d69a > 3ffe:80ee:a:0:201:3ff:fed5:bd1e: icmp6: 3ffe:80ee:1:0:204:76ff:fe97:d69a udp port 33434 unreachable (len 72, hlim 63) > > > 0x0000 6000 0000 0048 3a3f 3ffe 80ee 0001 0000 ....H:??....... > > > 0x0010 0204 76ff fe97 d69a 3ffe 80ee 000a 0000 ..v.....?....... > > > 0x0020 0201 03ff fed5 bd1e 0104 fb79 0000 0000 ...........y.... > > > 0x0030 6000 0000 0018 1101 3ffe 80ee 000a 0000 .......?....... > > > 0x0040 0201 03ff fed5 bd1e 3ffe 80ee 0001 0000 ........?....... > > > 0x0050 0204 76ff fe97 d69a 8018 829a 0018 0c82 ..v............. > > > 0x0060 0000 1df3 0000 0005 5b30 ae3f 3512 0200 ........[0.?5... > > > > > > > > > Jan > > > > > > From schuster.sven@gmx.de Sun Nov 9 06:48:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 09 Nov 2003 06:49:05 -0800 (PST) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA9Emo25030844 for ; Sun, 9 Nov 2003 06:48:51 -0800 Received: (qmail 15969 invoked by uid 65534); 9 Nov 2003 14:48:39 -0000 Received: from p50884561.dip0.t-ipconnect.de (EHLO gmx.de) (80.136.69.97) by mail.gmx.net (mp001) with SMTP; 09 Nov 2003 15:48:39 +0100 X-Authenticated: #2425915 Message-ID: <3FAE528B.6090002@gmx.de> Date: Sun, 09 Nov 2003 15:43:23 +0100 From: Sven Schuster User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: de-de, en, en-us MIME-Version: 1.0 To: Rask Ingemann Lambertsen CC: linux-net@vger.kernel.org, netdev Subject: Re: Linux <---> Unixware slow networking with e100 References: <3FA9F8D5.9020601@gmx.de> <20031109123435.B1282@sygehus.dk> In-Reply-To: <20031109123435.B1282@sygehus.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1289 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: schuster.sven@gmx.de Precedence: bulk X-list: netdev Rask Ingemann Lambertsen wrote: >On Thu, Nov 06, 2003 at 08:31:33AM +0100, Sven Schuster wrote: > > >>But when _receiving_ data from one of the unixware machines, we >>just get a few kB/s, max. about 100 kB/s. When _sending_ data to >>a unixware machine, the transfer rate is fine too. Are there any >>known issues between linux and unixware (except the SCO thing >>;-) ) ?? >> > >Run tcpdump and see what the window sizes are when sending data from >Unixware to Linux. > This actually seems to be a problem with either a switch in the network or with the onboard intel network card. I think it's one of the switches, or maybe the combination of those (one Planet FN-SW102 100 Mbit and one Foundry B15000 with the ports of our machines running at 100 Mbit), because we have the same slow transfer rates in this network from unixware to unixware. I did some tests yesterday directly from a redhat AS 2.1 to a unixware machine via cat. 7 crossover, and I didn't have any problems. And over a Planet switch (100 Mbit) there also were no problems. But thanks for your tip!! I'll get back and report what the issue was for the archives. Sven From mixxel@cs.auc.dk Sun Nov 9 12:53:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 09 Nov 2003 12:53:34 -0800 (PST) Received: from loke.sp-aarhus.dk (loke.sp-aarhus.dk [130.225.8.55]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA9KrI25009974 for ; Sun, 9 Nov 2003 12:53:19 -0800 Received: from 3e6b62de.rev.stofanet.dk ([62.107.98.222] helo=cs.auc.dk) by loke.sp-aarhus.dk with esmtp (Exim 3.35 #1 (Debian)) id 1AIvez-00080q-00; Sun, 09 Nov 2003 20:55:45 +0100 Message-ID: <3FAE9B9B.60007@cs.auc.dk> Date: Sun, 09 Nov 2003 20:55:07 +0100 From: Mikkel Christiansen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Emmanuel Fleury , "David S. Miller" , netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com Subject: Re: Announce: NetKeeper Firewall For Linux References: <1067285612.552.9.camel@aphrodite.olympus.net> <20031028014223.129933be.davem@redhat.com> <1067335655.10628.7.camel@rade7.s.cs.auc.dk> <1068001237.1064.31.camel@jzny.localdomain> <1068046114.31636.92.camel@rade7.s.cs.auc.dk> <1068089345.1020.17.camel@jzny.localdomain> <1068114376.1532.115.camel@rade7.s.cs.auc.dk> <1068211670.1031.49.camel@jzny.localdomain> In-Reply-To: <1068211670.1031.49.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 1290 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mixxel@cs.auc.dk Precedence: bulk X-list: netdev jamal wrote: >On Thu, 2003-11-06 at 05:26, Emmanuel Fleury wrote: > > > >>Ok, actually we were so focused on the classification scheme that we >>didn't really try to do something nice for the actions... In a matter of >>facts, we have only one action (log) and it is not even implemented. >> >>So, we will definitely look at your code to avoid us to have to think >>about this part (and avoid to have to recode the actions). >> >> >> > >I am asking you to switch to the TC code. I dont think i am making my >point across ;->[1]. Integrate your classifer like any other tc >classifier and then you dont have to look at my code unless you really >want to. > > > If we integrate it would mean a new/alternative interface to tc where you compile the filter/configuratoin before uploading. We believe this is a good thing since it allows admins to (syntax) check the filter before inserting it. I believe the guys from shorewall sees this as a missing feature of iptables. Would you consider such an interface for tc good are bad? >>>Anything that requires "connection setup" to dynamically add rules is a >>>candidate. Think Voip SIP Proxy server for example which will insert >>>rules; think any authentication schemes that are needed before >>>installing rules, think tcp-splicing etc. >>> >>> >>Ok, but you are speaking about non permanent rules (aka dynamic rules). >> >> >> > >These types are most dominant these days in my opinion unless you are a >single user behind a DSL line. > > > >>The idea we have to handle stateful inspection is to have the core >>filter (totally static) plus some "state" nodes placed inside the IDD >>which are calling a function to evaluate the "state" of the packet >>(based on some informations given by the packet header and a database of >>the open connections). >> >> > >Isnt the state database another classifier and therefore you will be >faced with the same challenges for it? >I dont think you wuill get a free ride putting the state lookups >somewhere else. > > > current scheme cant handle dynamic rules - and it will be a while (if ever) before it can. >>When reaching the terminals, one of the action >>can be to change the state of the connection. >> >> > >tc allows you to have multiple cascaded classifiers; so >you could "reclassify" and jump to a state classifier. >I think the other guys from .dk also had their own scheme of achieving >the same goal. Being able to do this in my opinion is architecturally >cleaner. > > > >>I guess that what you describe can be handled by such mechanism >>(better than changing the ruleset each time). As it is handled outside >>of the IDD, this take only the time of the look-up in the database and >>the time to modify the database (when necessary). >> >> >> > >This is true if you consider the state database to be a different >problem other than a classification one. > > > >>But, I over simplified things here, this scheme is far from being ready >>at this point. We should investigate it more in depth (we need more >>time!!!). >> >> >> > >no problem. > > > >>>I think thats a design issue. For example while u32 classifier may not >>>process as fast as you (lookups would take longer relatively ) - its >>>insertion time is independent of the complexity of the rules. >>>Lakshman (sp?) had a good paper on the tradeoffs between memory space >>>used, lookup times and insertion times (there was another variable) and >>>i think he may have proved you cant have all of them work well at the >>>same time. >>> >>> >>Ok. Could you give more details about the references of this paper from >>Lakshman ? >> >> >> > >You are in academia, you better make sure you are aware of these >things ;-> > > > >The Lakshman paper describes an algorithm but i remember it was the >first to introduce classification constraints: > >T.V.Lakshman and D.Stiliadis. High Speed Policy-based Packet Forwarding >Using Efficient Multi-dimensional Range Matching. Proceedings of ACM >Sigcomm98 > >Another good paper to look at is: > >A.Feldmann and S.Muthukrishnan. Tradeoffs for packet classification. >Proceedings of IEEE Infocom2000 > > > >>I am wrong here, terribly wrong. The thing is that is you add a rule at >>the end of your filter, you will not have to rebuild it, but inserting a >>rule randomly in the list is... bad. For now, we don't have any good >>algorithm to insert a rule, so we just rebuild the whole thing. >> >> >> > >Then you have some work to do > > > >>>>When coding in the kernel, we are coding with the idea that: >>>> « The kernel should defend itself against user-space. » >>>> >>>>So, when the user say: "Commit". >>>> >>>>The kernel will first check the decision diagram for safety (no NULL >>>>pointers, out of range variables, no loops, etc) and depending of the >>>>tests, will take the decision to commit or not. >>>> >>>> >>>That sounds more like still a user space problem ;-> >>> >>> >>No. >> >>Users shouldn't be able to break the kernel just by misconfiguring it. >> >> >> > >Couldnt you, knowing the rules already existing check for breakage in >user space? > > > no - if someone decided to write their own "client/compiler" in userspace they could potentially produce a broken IDD - that could crash the kernel! >>>I saw in your paper briefly that you have infact a checker for something >>>like this. >>> >>> >>If you are speaking about the "network access verifier", it is something >>totally different. But, I might have misunderstood you. >> >> >> > >I meant that network access verifier. I believe you should be able to >verify things not only just in user space bu even in a remote location >(example a network management station). Now this stuff is interesting. > > > >>>In my view the most important issues in priority order are: >>>lookup speed regardless of table size, insert/delete rate regardless of >>>table size, Capacity (should be able to go to the hundreds of thousands >>>of flows), memory use for storage purposes - although i dont really care >>>very much about these since memory is cheap these days. >>> >>> >>Ok, I think we have to work on the insert/delete part. I know for a fact >>that insert/delete inside the IDD is not an option (as the complexity of >>this operation is too high), so we will look at some other way to handle >>it. >> >> >> > >cool. Looking forward to see some of your thoughts on this when you have >experienced it. > >cheers, >jamal > >[1] Look at your action code dispatch name and my old one and note the >name being _exactly_ the same. I dont think it is a big coincidence and >i dont think you had any bad intent. I am just saying you can continue >doing that or you can integrate. Why dont we drop this part of the >discussion if you dont wanna move forward to the tc code? I thought you >agreed with Dave to integrate ;-> > > > Well, then you need to think again - it is in fact a coincidence! Cheers Mikkel From yoshfuji@linux-ipv6.org Sun Nov 9 13:59:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 09 Nov 2003 13:59:51 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA9Lxb25010892 for ; Sun, 9 Nov 2003 13:59:37 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-6.6) with ESMTP id hA9Lxqlg032593; Mon, 10 Nov 2003 06:59:53 +0900 Date: Sun, 09 Nov 2003 15:59:52 -0600 (CST) Message-Id: <20031109.155952.106613268.yoshfuji@linux-ipv6.org> To: davem@redhat.com CC: netdev@oss.sgi.com Subject: [PATCH 2/2] [IPV{4,6}] Normalize jiffies values reported to userspace From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1292 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello. [2/2] [IPV{4,6}] Normalize jiffies values reported to userspace ===== net/ipv4/route.c 1.73 vs edited ===== --- 1.73/net/ipv4/route.c Tue Oct 7 23:54:12 2003 +++ edited/net/ipv4/route.c Mon Nov 10 06:34:08 2003 @@ -89,6 +89,7 @@ #include #include #include +#include #include #include #include @@ -2309,7 +2310,7 @@ ci.rta_used = rt->u.dst.__use; ci.rta_clntref = atomic_read(&rt->u.dst.__refcnt); if (rt->u.dst.expires) - ci.rta_expires = rt->u.dst.expires - jiffies; + ci.rta_expires = jiffies_to_clock_t(rt->u.dst.expires - jiffies); else ci.rta_expires = 0; ci.rta_error = rt->u.dst.error; ===== net/ipv6/route.c 1.58 vs edited ===== --- 1.58/net/ipv6/route.c Sun Aug 31 13:26:12 2003 +++ edited/net/ipv6/route.c Mon Nov 10 06:34:08 2003 @@ -27,6 +27,7 @@ #include #include #include +#include #include #include #include @@ -717,7 +718,7 @@ return -ENOMEM; rt->u.dst.obsolete = -1; - rt->rt6i_expires = rtmsg->rtmsg_info; + rt->rt6i_expires = clock_t_to_jiffies(rtmsg->rtmsg_info); if (nlh && (r = NLMSG_DATA(nlh))) { rt->rt6i_protocol = r->rtm_protocol; } else { @@ -1535,7 +1536,7 @@ RTA_PUT(skb, RTA_PRIORITY, 4, &rt->rt6i_metric); ci.rta_lastuse = jiffies - rt->u.dst.lastuse; if (rt->rt6i_expires) - ci.rta_expires = rt->rt6i_expires - jiffies; + ci.rta_expires = jiffies_to_clock_t(rt->rt6i_expires - jiffies); else ci.rta_expires = 0; ci.rta_used = rt->u.dst.__use; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Sun Nov 9 13:59:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 09 Nov 2003 13:59:26 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA9LxC25010856 for ; Sun, 9 Nov 2003 13:59:12 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-6.6) with ESMTP id hA9LxQlg032590; Mon, 10 Nov 2003 06:59:26 +0900 Date: Sun, 09 Nov 2003 15:59:25 -0600 (CST) Message-Id: <20031109.155925.112987543.yoshfuji@linux-ipv6.org> To: davem@redhat.com CC: netdev@oss.sgi.com Subject: [PATCH 1/2] linux/times.h needs asm/param.h From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1291 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev [1/1] linux/times.h needs asm/param.h linux/times.h depends on asm/param.h (USER_HZ). ===== include/linux/times.h 1.4 vs edited ===== --- 1.4/include/linux/times.h Fri Jul 18 01:54:48 2003 +++ edited/include/linux/times.h Mon Nov 10 06:34:07 2003 @@ -4,6 +4,7 @@ #ifdef __KERNEL__ #include #include +#include #if (HZ % USER_HZ)==0 # define jiffies_to_clock_t(x) ((x) / (HZ / USER_HZ)) -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From rddunlap@osdl.org Sun Nov 9 15:29:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 09 Nov 2003 15:29:29 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA9NTD25013076 for ; Sun, 9 Nov 2003 15:29:14 -0800 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id hA9NT4C24939; Sun, 9 Nov 2003 15:29:04 -0800 Date: Sun, 9 Nov 2003 15:26:43 -0800 From: "Randy.Dunlap" To: Rask Ingemann Lambertsen Cc: netdev@oss.sgi.com, saw@saw.sw.com.sg, akpm@osdl.org Subject: Re: [PATCH] enabling netdev boot options (2.6.0-t9) Message-Id: <20031109152643.73688224.rddunlap@osdl.org> In-Reply-To: <20031109115535.A1282@sygehus.dk> References: <20031108160441.3a0a5505.rddunlap@osdl.org> <20031108204406.5dbbdc87.rddunlap@osdl.org> <20031109115535.A1282@sygehus.dk> Organization: OSDL X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1293 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev On Sun, 9 Nov 2003 11:55:35 +0100 Rask Ingemann Lambertsen wrote: | I don't like that name for the function. dev_alloc_name_lock() makes it | natural to think that there is a matching dev_alloc_name_unlock() function | which you should call afterwards. How about dev_alloc_name_locked() or | dev_alloc_name_with_lock() instead? I didn't like that name either. Now changed to dev_alloc_name_locked() and exported. Take 3 below. More comments? -- ~Randy description: enable eepro100 and 3c59x drivers to recognize 'netdev=' boot options: use dev_alloc_name() to assign an interface name if rtnl lock is already held (eepro100); use [new] dev_alloc_name_locked() to assign interface name if required lock is not already held; then use netdev_boot_setup_check() to check for boot options for that interface (name); add dev_alloc_name_locked() to net/core/dev.c; export dev_alloc_name_locked() for modules; maintainer: Andrey V. Savochkin (saw@saw.sw.com.sg); Andrew Morton (akpm@osdl.org) et al product_versions: Linux 2.6.0-test9 diffstat:= drivers/net/3c59x.c | 6 ++++++ drivers/net/eepro100.c | 12 +++++++----- include/linux/netdevice.h | 1 + net/core/dev.c | 24 ++++++++++++++++++++++++ 4 files changed, 38 insertions(+), 5 deletions(-) diff -Naurp ./drivers/net/eepro100.c~netdev ./drivers/net/eepro100.c --- ./drivers/net/eepro100.c~netdev 2003-10-25 11:44:01.000000000 -0700 +++ ./drivers/net/eepro100.c 2003-11-08 20:05:38.000000000 -0800 @@ -681,17 +681,19 @@ static int __devinit speedo_found1(struc SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); - if (dev->mem_start > 0) + rtnl_lock(); + + if (dev_alloc_name(dev, dev->name) < 0) + goto err_free_unlock; + + if (netdev_boot_setup_check(dev) && dev->mem_start > 0) { option = dev->mem_start; + } else if (card_idx >= 0 && options[card_idx] >= 0) option = options[card_idx]; else option = 0; - rtnl_lock(); - if (dev_alloc_name(dev, dev->name) < 0) - goto err_free_unlock; - /* Read the station address EEPROM before doing the reset. Nominally his should even be done before accepting the device, but then we wouldn't have a device name with which to report the error. diff -Naurp ./drivers/net/3c59x.c~netdev ./drivers/net/3c59x.c --- ./drivers/net/3c59x.c~netdev 2003-10-25 11:42:42.000000000 -0700 +++ ./drivers/net/3c59x.c 2003-11-09 15:13:01.000000000 -0800 @@ -1110,6 +1110,12 @@ static int __devinit vortex_probe1(struc SET_NETDEV_DEV(dev, gendev); vp = dev->priv; + retval = dev_alloc_name_locked(dev, dev->name); + if (retval < 0) + goto free_region; + + netdev_boot_setup_check(dev); + option = global_options; /* The lower four bits are the media type. */ diff -Naurp ./net/core/dev.c~netdev ./net/core/dev.c --- ./net/core/dev.c~netdev 2003-10-25 11:43:39.000000000 -0700 +++ ./net/core/dev.c 2003-11-09 15:04:10.000000000 -0800 @@ -635,6 +635,29 @@ int dev_alloc_name(struct net_device *de } /** + * dev_alloc_name_locked - allocate a name for a device, + * with required locking + * @dev: device + * @name: name format string + * + * Passed a format string - eg "lt%d" it will try and find a suitable + * id. Not efficient for many devices, not called a lot. + * This function takes the rtnl lock while allocating the name and + * adding the device in order to avoid duplicates. + * Returns the number of the unit assigned or a negative errno code. + */ + +int dev_alloc_name_locked(struct net_device *dev, const char *name) +{ + int ret; + + rtnl_lock(); + ret = dev_alloc_name(dev, name); + rtnl_unlock(); + return ret; +} + +/** * dev_alloc - allocate a network device and name * @name: name format string * @err: error return pointer @@ -3035,6 +3058,7 @@ EXPORT_SYMBOL(call_netdevice_notifiers); EXPORT_SYMBOL(dev_add_pack); EXPORT_SYMBOL(__dev_alloc); EXPORT_SYMBOL(dev_alloc_name); +EXPORT_SYMBOL(dev_alloc_name_locked); EXPORT_SYMBOL(dev_close); EXPORT_SYMBOL(dev_get_by_flags); EXPORT_SYMBOL(dev_get_by_index); diff -Naurp ./include/linux/netdevice.h~netdev ./include/linux/netdevice.h --- ./include/linux/netdevice.h~netdev 2003-10-25 11:44:45.000000000 -0700 +++ ./include/linux/netdevice.h 2003-11-09 15:13:41.000000000 -0800 @@ -518,6 +518,7 @@ static inline __deprecated struct net_de return __dev_alloc(name, err); } extern int dev_alloc_name(struct net_device *dev, const char *name); +extern int dev_alloc_name_locked(struct net_device *dev, const char *name); extern int dev_open(struct net_device *dev); extern int dev_close(struct net_device *dev); extern int dev_queue_xmit(struct sk_buff *skb); From davem@pizda.ninka.net Sun Nov 9 19:30:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 09 Nov 2003 19:31:07 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAA3Uq25018584 for ; Sun, 9 Nov 2003 19:30:52 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id TAA11921; Sun, 9 Nov 2003 19:25:02 -0800 Date: Sun, 9 Nov 2003 19:25:02 -0800 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2/2] [IPV{4,6}] Normalize jiffies values reported to userspace Message-Id: <20031109192502.4f60783b.davem@redhat.com> In-Reply-To: <20031109.155952.106613268.yoshfuji@linux-ipv6.org> References: <20031109.155952.106613268.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1294 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 09 Nov 2003 15:59:52 -0600 (CST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > [1/1] linux/times.h needs asm/param.h > [2/2] [IPV{4,6}] Normalize jiffies values reported to userspace Both patches applied, arigato Yoshfuji-san. From fdonzet@yahoo.fr Mon Nov 10 00:14:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 00:15:01 -0800 (PST) Received: from web25201.mail.ukl.yahoo.com (web25201.mail.ukl.yahoo.com [217.12.10.61]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAA8EN25025114 for ; Mon, 10 Nov 2003 00:14:24 -0800 Message-ID: <20031110081417.55732.qmail@web25201.mail.ukl.yahoo.com> Received: from [195.68.44.148] by web25201.mail.ukl.yahoo.com via HTTP; Mon, 10 Nov 2003 09:14:17 CET Date: Mon, 10 Nov 2003 09:14:17 +0100 (CET) From: =?iso-8859-1?q?francois=20donzet?= Subject: Re: problem in driver network code To: Rask Ingemann Lambertsen Cc: netdev@oss.sgi.com In-Reply-To: <20031107181508.A1102@sygehus.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 1295 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fdonzet@yahoo.fr Precedence: bulk X-list: netdev --- Rask Ingemann Lambertsen a écrit : > On Fri, Nov 07, 2003 at 09:38:44AM +0100, francois > donzet wrote: > > > > It seems to me that there is a problem ;). If i > store > > in skb->csum a sum of all words of the packet > data, it > > will be unusable by tcp (the skb->csum doesn't > > contain the checksum of tcpheader plus data only, > as > > the ipheader is part of the packet when the sum is > > computed) > > That can be accounted for by the TCP code because > the IP header is known to > the TCP code. IIRC, the pseudoheader is similiar to > a real IP header, so it > may take just a few lines of code to make up for the > difference, but I > haven't checked that. The theory seems fine, but there is no clue of this way in the code. > What do you do with an IEEE 802.1q (VLAN) or 802.2 > (LLC) packet? The VLAN > code in vlan_skb_recv() does not adjust skb->csum or > skb->ip_summed. Neither > does the 802.2 code. no matter the link layer header is 802.3,802.2 or 8021.q . Tcp checksum offloading is supported, whatever the type of the link layer (as skb->csum is computed without the link layer header). ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com From fdonzet@yahoo.fr Mon Nov 10 03:29:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 03:29:39 -0800 (PST) Received: from web25201.mail.ukl.yahoo.com (web25201.mail.ukl.yahoo.com [217.12.10.61]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAABTL25031375 for ; Mon, 10 Nov 2003 03:29:21 -0800 Message-ID: <20031110112915.3483.qmail@web25201.mail.ukl.yahoo.com> Received: from [195.68.44.148] by web25201.mail.ukl.yahoo.com via HTTP; Mon, 10 Nov 2003 12:29:15 CET Date: Mon, 10 Nov 2003 12:29:15 +0100 (CET) From: =?iso-8859-1?q?francois=20donzet?= Subject: checksum offloading To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 1296 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fdonzet@yahoo.fr Precedence: bulk X-list: netdev Hi, i have a little question : When tcp checksum offloading is enabled, the chip computes a sum on all words of the packet contents and stores the result in skb->csum, setting skb->ip_summed to CHECKSUM_HW. (see for example, e100_main.c) Then, when packet reaches tcp layer, via tcp_checksum_init(), tcp checksum is verified (using together skb->csum and the pseudo header checksum). How does TCP deal with skb->csum, as it doesn't cover only the tcpheader+data (but ipheader+tcpheader+data) Thanks. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com From filia@softhome.net Mon Nov 10 03:10:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 03:34:57 -0800 (PST) Received: from natsmtp01.rzone.de (natsmtp01.rzone.de [81.169.145.166]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAABAp25031214 for ; Mon, 10 Nov 2003 03:10:52 -0800 Received: from softhome.net ([212.18.200.6]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id hAABAlOw000089; Mon, 10 Nov 2003 12:10:48 +0100 (MET) Message-ID: <3FAF7236.7020209@softhome.net> Date: Mon, 10 Nov 2003 12:10:46 +0100 From: "Ihar 'Philips' Filipau" Organization: Home Sweet Home User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030927 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux Kernel Mailing List CC: netdev@oss.sgi.com Subject: net/packet/af_packet.c:{1057,1073}: flags vs. msg->flags Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1297 X-Approved-By: ralf@linux-mips.org X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: filia@softhome.net Precedence: bulk X-list: netdev Hi! [ I'm trying to cc: netdev - but they are not that welcome - and require subscription. I'm way too lazy (and my mail box is not that fast) to subscribe to send simple typo - if this is a case at all. ] [ kernel v2.6.0-test7 as found on lxr.linux.no, 2.4.{18,22} has the same - but line numbers are different. ] On line 1057 we have: "msg->msg_flags|=MSG_TRUNC;" to indicate that message was truncated. But on line 1073, where we make return status to user, we check against user suplied flags, but NOT msg->msg_flags. It looks like obvious typo. -- Ihar 'Philips' Filipau / with best regards from Saarbruecken. -- _ _ _ "... and for $64000 question, could you get yourself |_|*|_| vaguely familiar with the notion of on-topic posting?" |_|_|*| -- Al Viro @ LKML |*|*|*| From hno@marasystems.com Mon Nov 10 07:12:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 07:12:50 -0800 (PST) Received: from filer.marasystems.com (marasystems.com [213.150.153.194]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAAFCN25006918 for ; Mon, 10 Nov 2003 07:12:25 -0800 Received: from localhost (henrik@localhost) by filer.marasystems.com (8.11.6/8.11.6) with ESMTP id hAAFC4F04138; Mon, 10 Nov 2003 16:12:04 +0100 Date: Mon, 10 Nov 2003 16:12:04 +0100 (CET) From: Henrik Nordstrom X-X-Sender: henrik@filer.marasystems.com To: Mikkel Christiansen cc: hadi@cyberus.ca, Emmanuel Fleury , "David S. Miller" , , Subject: Re: Announce: NetKeeper Firewall For Linux In-Reply-To: <3FAE9B9B.60007@cs.auc.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1298 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hno@marasystems.com Precedence: bulk X-list: netdev On Sun, 9 Nov 2003, Mikkel Christiansen wrote: > uploading. We believe this is a good thing since it allows > admins to (syntax) check the filter before inserting it. > I believe the guys from shorewall sees this as a missing > feature of iptables. See iptables-restore. It is exacly this (compile whole ruleset before insert) for iptables. The only thing missing is that it only compiles one table at a time. Regards Henrik From yoshfuji@linux-ipv6.org Mon Nov 10 08:45:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 08:45:55 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAAGjK25011460 for ; Mon, 10 Nov 2003 08:45:41 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-6.6) with ESMTP id hAAGjalg004853; Tue, 11 Nov 2003 01:45:36 +0900 Date: Mon, 10 Nov 2003 10:45:36 -0600 (CST) Message-Id: <20031110.104536.79654717.yoshfuji@linux-ipv6.org> To: davem@redhat.com CC: netdev@oss.sgi.com Subject: [PATCH] NET: Normalize jiffies reported to userspace, in neighbor management code From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1299 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello. more jiffies normalizations reported to userspace, in core/neighbour.c. ===== include/linux/sysctl.h 1.53 vs edited ===== --- 1.53/include/linux/sysctl.h Thu Oct 30 05:19:30 2003 +++ edited/include/linux/sysctl.h Tue Nov 11 01:12:31 2003 @@ -726,6 +726,8 @@ void __user *, size_t *); extern int proc_dointvec_jiffies(ctl_table *, int, struct file *, void __user *, size_t *); +extern int proc_dointvec_userhz_jiffies(ctl_table *, int, struct file *, + void __user *, size_t *); extern int proc_doulongvec_minmax(ctl_table *, int, struct file *, void __user *, size_t *); extern int proc_doulongvec_ms_jiffies_minmax(ctl_table *table, int, ===== kernel/sysctl.c 1.55 vs edited ===== --- 1.55/kernel/sysctl.c Thu Oct 2 16:12:07 2003 +++ edited/kernel/sysctl.c Tue Nov 11 01:12:32 2003 @@ -37,6 +37,7 @@ #include #include #include +#include #include #ifdef CONFIG_ROOT_NFS @@ -1750,6 +1751,114 @@ return do_proc_dointvec(table,write,filp,buffer,lenp,HZ,OP_SET); } +/** + * proc_dointvec_userhz_jiffies - read a vector of integers as 1/USER_HZ seconds + * @table: the sysctl table + * @write: %TRUE if this is a write to the sysctl file + * @filp: the file structure + * @buffer: the user buffer + * @lenp: the size of the user buffer + * + * Reads/writes up to table->maxlen/sizeof(unsigned int) integer + * values from/to the user buffer, treated as an ASCII string. + * The values read are assumed to be in 1/USER_HZ seconds, and + * are converted into jiffies. + * + * Returns 0 on success. + */ +int proc_dointvec_userhz_jiffies(ctl_table *table, int write, struct file *filp, + void __user *buffer, size_t *lenp) +{ + int *i, vleft, first=1, neg, val; + size_t left, len; + + #define TMPBUFLEN 20 + char buf[TMPBUFLEN], *p; + + if (!table->data || !table->maxlen || !*lenp || + (filp->f_pos && !write)) { + *lenp = 0; + return 0; + } + + i = (int *) table->data; + vleft = table->maxlen / sizeof(int); + left = *lenp; + + for (; left && vleft--; i++, first=0) { + if (write) { + while (left) { + char c; + if (get_user(c,(char __user *) buffer)) + return -EFAULT; + if (!isspace(c)) + break; + left--; + buffer++; + } + if (!left) + break; + neg = 0; + len = left; + if (len > TMPBUFLEN-1) + len = TMPBUFLEN-1; + if(copy_from_user(buf, buffer, len)) + return -EFAULT; + buf[len] = 0; + p = buf; + if (*p == '-' && left > 1) { + neg = 1; + left--, p++; + } + if (*p < '0' || *p > '9') + break; + val = clock_t_to_jiffies(simple_strtoul(p, &p, 0)); + len = p-buf; + if ((len < left) && *p && !isspace(*p)) + break; + if (neg) + val = -val; + buffer += len; + left -= len; + *i = val; + } else { + p = buf; + if (!first) + *p++ = '\t'; + sprintf(p, "%d", jiffies_to_clock_t(*i)); + len = strlen(buf); + if (len > left) + len = left; + if(copy_to_user(buffer, buf, len)) + return -EFAULT; + left -= len; + buffer += len; + } + } + + if (!write && !first && left) { + if(put_user('\n', (char *) buffer)) + return -EFAULT; + left--, buffer++; + } + if (write) { + p = (char *) buffer; + while (left) { + char c; + if(get_user(c, p++)) + return -EFAULT; + if (!isspace(c)) + break; + left--; + } + } + if (write && first) + return -EINVAL; + *lenp -= left; + filp->f_pos += *lenp; + return 0; +} + #else /* CONFIG_PROC_FS */ int proc_dostring(ctl_table *table, int write, struct file *filp, @@ -1788,6 +1897,12 @@ return -ENOSYS; } +int proc_dointvec_userhz_jiffies(ctl_table *table, int write, struct file *filp, + void *buffer, size_t *lenp) +{ + return -ENOSYS; +} + int proc_doulongvec_minmax(ctl_table *table, int write, struct file *filp, void *buffer, size_t *lenp) { @@ -1975,6 +2090,12 @@ return -ENOSYS; } +int proc_dointvec_userhz_jiffies(ctl_table *table, int write, struct file *filp, + void *buffer, size_t *lenp) +{ + return -ENOSYS; +} + int proc_doulongvec_minmax(ctl_table *table, int write, struct file *filp, void __user *buffer, size_t *lenp) { @@ -2007,6 +2128,7 @@ EXPORT_SYMBOL(proc_dointvec); EXPORT_SYMBOL(proc_dointvec_jiffies); EXPORT_SYMBOL(proc_dointvec_minmax); +EXPORT_SYMBOL(proc_dointvec_userhz_jiffies); EXPORT_SYMBOL(proc_dostring); EXPORT_SYMBOL(proc_doulongvec_minmax); EXPORT_SYMBOL(proc_doulongvec_ms_jiffies_minmax); ===== net/core/neighbour.c 1.20 vs edited ===== --- 1.20/net/core/neighbour.c Tue Oct 21 14:59:11 2003 +++ edited/net/core/neighbour.c Tue Nov 11 01:12:34 2003 @@ -24,6 +24,7 @@ #ifdef CONFIG_SYSCTL #include #endif +#include #include #include #include @@ -1510,7 +1511,7 @@ .procname = "retrans_time", .maxlen = sizeof(int), .mode = 0644, - .proc_handler = &proc_dointvec, + .proc_handler = &proc_dointvec_userhz_jiffies, }, { .ctl_name = NET_NEIGH_REACHABLE_TIME, @@ -1552,21 +1553,21 @@ .procname = "anycast_delay", .maxlen = sizeof(int), .mode = 0644, - .proc_handler = &proc_dointvec, + .proc_handler = &proc_dointvec_userhz_jiffies, }, { .ctl_name = NET_NEIGH_PROXY_DELAY, .procname = "proxy_delay", .maxlen = sizeof(int), .mode = 0644, - .proc_handler = &proc_dointvec, + .proc_handler = &proc_dointvec_userhz_jiffies, }, { .ctl_name = NET_NEIGH_LOCKTIME, .procname = "locktime", .maxlen = sizeof(int), .mode = 0644, - .proc_handler = &proc_dointvec, + .proc_handler = &proc_dointvec_userhz_jiffies, }, { .ctl_name = NET_NEIGH_GC_INTERVAL, -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Mon Nov 10 08:48:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 08:48:40 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAAGmR25014594 for ; Mon, 10 Nov 2003 08:48:27 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-6.6) with ESMTP id hAAGmhlg004896; Tue, 11 Nov 2003 01:48:43 +0900 Date: Mon, 10 Nov 2003 10:48:43 -0600 (CST) Message-Id: <20031110.104843.65576225.yoshfuji@linux-ipv6.org> To: davem@redhat.com CC: netdev@oss.sgi.com Subject: [PATCH] DECNET: Normalize jiffies reported to userspace From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1300 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello. jiffies normalization for decnet. ===== net/decnet/dn_route.c 1.18 vs edited ===== --- 1.18/net/decnet/dn_route.c Wed Jul 23 15:33:06 2003 +++ edited/net/decnet/dn_route.c Tue Nov 11 01:31:31 2003 @@ -77,6 +77,7 @@ #include #include #include +#include #include #include #include @@ -1508,11 +1509,11 @@ RTA_PUT(skb, RTA_GATEWAY, 2, &rt->rt_gateway); if (rtnetlink_put_metrics(skb, rt->u.dst.metrics) < 0) goto rtattr_failure; - ci.rta_lastuse = jiffies - rt->u.dst.lastuse; + ci.rta_lastuse = jiffies_to_clock_t(jiffies - rt->u.dst.lastuse); ci.rta_used = rt->u.dst.__use; ci.rta_clntref = atomic_read(&rt->u.dst.__refcnt); if (rt->u.dst.expires) - ci.rta_expires = rt->u.dst.expires - jiffies; + ci.rta_expires = jiffies_to_clock_t(rt->u.dst.expires - jiffies); else ci.rta_expires = 0; ci.rta_error = rt->u.dst.error; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Mon Nov 10 08:50:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 08:50:20 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAAGo625014950 for ; Mon, 10 Nov 2003 08:50:07 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-6.6) with ESMTP id hAAGoNlg004930; Tue, 11 Nov 2003 01:50:23 +0900 Date: Mon, 10 Nov 2003 10:50:23 -0600 (CST) Message-Id: <20031110.105023.116811039.yoshfuji@linux-ipv6.org> To: davem@redhat.com CC: netdev@oss.sgi.com Subject: [PATCH] IPV{4,6}: Normalize jiffies reported to userspace in routing code (missing pieces) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1301 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Sorry, I failed to fix these bits. ===== net/ipv4/route.c 1.74 vs edited ===== --- 1.74/net/ipv4/route.c Mon Nov 10 12:26:48 2003 +++ edited/net/ipv4/route.c Tue Nov 11 01:43:28 2003 @@ -2306,7 +2306,7 @@ RTA_PUT(skb, RTA_GATEWAY, 4, &rt->rt_gateway); if (rtnetlink_put_metrics(skb, rt->u.dst.metrics) < 0) goto rtattr_failure; - ci.rta_lastuse = jiffies - rt->u.dst.lastuse; + ci.rta_lastuse = jiffies_to_clock_t(jiffies - rt->u.dst.lastuse); ci.rta_used = rt->u.dst.__use; ci.rta_clntref = atomic_read(&rt->u.dst.__refcnt); if (rt->u.dst.expires) ===== net/ipv6/route.c 1.59 vs edited ===== --- 1.59/net/ipv6/route.c Mon Nov 10 12:26:48 2003 +++ edited/net/ipv6/route.c Tue Nov 11 01:42:00 2003 @@ -1534,7 +1534,7 @@ if (rt->u.dst.dev) RTA_PUT(skb, RTA_OIF, sizeof(int), &rt->rt6i_dev->ifindex); RTA_PUT(skb, RTA_PRIORITY, 4, &rt->rt6i_metric); - ci.rta_lastuse = jiffies - rt->u.dst.lastuse; + ci.rta_lastuse = jiffies_to_clock_t(jiffies - rt->u.dst.lastuse); if (rt->rt6i_expires) ci.rta_expires = jiffies_to_clock_t(rt->rt6i_expires - jiffies); else -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From pp@ee.oulu.fi Mon Nov 10 10:19:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 10:19:34 -0800 (PST) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAAIJJ25023776 for ; Mon, 10 Nov 2003 10:19:20 -0800 Received: from tk28.oulu.fi (tk28 [130.231.48.68]) by ee.oulu.fi (8.12.10/8.12.10) with ESMTP id hAAIJHf2012689 for ; Mon, 10 Nov 2003 20:19:17 +0200 (EET) Received: (from pp@localhost) by tk28.oulu.fi (8.12.10/8.12.10/Submit) id hAAIJHNl025857 for netdev@oss.sgi.com; Mon, 10 Nov 2003 20:19:17 +0200 (EET) Date: Mon, 10 Nov 2003 20:19:17 +0200 From: Pekka Pietikainen To: netdev@oss.sgi.com Subject: [patch] 2.4 lacks dummy SET_NETDEV_DEV Message-ID: <20031110181917.GA25846@ee.oulu.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 1302 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pp@ee.oulu.fi Precedence: bulk X-list: netdev Just noticed that 2.4 doesn't have a dummy SET_NETDEV_DEV for drivers written for 2.6 (like the b44 fixes that got merged a few days back, so it wouldn't actually compile :-) ) --- linux-2.4.22/include/linux/netdevice.h.orig 2003-10-03 20:30:14.000000000 +0300 +++ linux-2.4.22/include/linux/netdevice.h 2003-11-10 20:12:46.480609408 +0200 @@ -454,6 +454,8 @@ #endif /* CONFIG_NET_DIVERT */ }; +/* 2.6 compatibility */ +#define SET_NETDEV_DEV(net, pdev) do { } while (0) struct packet_type { From riel@redhat.com Mon Nov 10 13:31:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 13:31:47 -0800 (PST) Received: from chimarrao.boston.redhat.com (nat-pool-bos.redhat.com [66.187.230.200]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAALVV25029471 for ; Mon, 10 Nov 2003 13:31:31 -0800 Received: from chimarrao.boston.redhat.com (localhost.localdomain [127.0.0.1]) by chimarrao.boston.redhat.com (8.12.8/8.12.8) with ESMTP id hAALVUeh002978; Mon, 10 Nov 2003 16:31:30 -0500 Received: from localhost (riel@localhost) by chimarrao.boston.redhat.com (8.12.8/8.12.8/Submit) with ESMTP id hAALVTap002975; Mon, 10 Nov 2003 16:31:29 -0500 X-Authentication-Warning: chimarrao.boston.redhat.com: riel owned process doing -bs Date: Mon, 10 Nov 2003 16:31:29 -0500 (EST) From: Rik van Riel X-X-Sender: riel@chimarrao.boston.redhat.com To: Dave Miller cc: linux-kernel@vger.kernel.org, Subject: 2.6 ipv6 doesn't take route advertisements Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1303 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: riel@redhat.com Precedence: bulk X-list: netdev Hi, it looks like the 2.6 kernel doesn't take default route advertisements from either zebra or radvd. I can see the default routes being advertised with radvdump, but they don't show up in the routing table of either of my 2.6 machines. They both run a fairly recent 2.6 kernel. Known bug ? -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From gandalf@wlug.westbo.se Mon Nov 10 13:59:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 13:59:15 -0800 (PST) Received: from null.rsn.bth.se (postfix@null.rsn.bth.se [194.47.142.3]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAALx125031012 for ; Mon, 10 Nov 2003 13:59:02 -0800 Received: by null.rsn.bth.se (Postfix, from userid 65534) id AACEB2C0013; Mon, 10 Nov 2003 22:58:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by null.rsn.bth.se (Postfix) with ESMTP id 562092C0014; Mon, 10 Nov 2003 22:58:57 +0100 (CET) Received: from null.rsn.bth.se ([127.0.0.1]) by localhost (null [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 23256-10; Mon, 10 Nov 2003 22:58:56 +0100 (CET) Received: from tux.rsn.bth.se (tux.rsn.bth.se [194.47.143.135]) by null.rsn.bth.se (Postfix) with ESMTP id BD4742C0013; Mon, 10 Nov 2003 22:58:56 +0100 (CET) Received: by tux.rsn.bth.se (Postfix, from userid 501) id 496754408; Mon, 10 Nov 2003 22:58:57 +0100 (CET) Subject: Re: 2.6 ipv6 doesn't take route advertisements From: Martin Josefsson To: Rik van Riel Cc: Dave Miller , linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-JE8rCjEXJ8wazuw75Pzj" Message-Id: <1068501536.774.1.camel@tux.rsn.bth.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 10 Nov 2003 22:58:57 +0100 X-Virus-Scanned: by amavisd-new-20030616-p5 X-archive-position: 1304 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gandalf@wlug.westbo.se Precedence: bulk X-list: netdev --=-JE8rCjEXJ8wazuw75Pzj Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2003-11-10 at 22:31, Rik van Riel wrote: > Hi, >=20 > it looks like the 2.6 kernel doesn't take default route > advertisements from either zebra or radvd. I can see > the default routes being advertised with radvdump, but > they don't show up in the routing table of either of my > 2.6 machines. They both run a fairly recent 2.6 kernel. >=20 > Known bug ? Works fine here with test9-bk15 Router runs radvd. default dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 metric10 6= 4 default dev eth2 proto kernel metric 256 mtu 1500 advmss 1440 metric10 6= 4 default via fe80::202:b3ff:fe5f:11fd dev eth0 proto kernel metric 1024 e= xpires 1788sec mtu 1500 advmss 1440 metric10 64 --=20 /Martin --=-JE8rCjEXJ8wazuw75Pzj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/sAofWm2vlfa207ERAl3aAKCFBsQN6V2ftFEyssROiv5wmN5NLwCfbmQP /lEiXbz/YuRCVL8c/zjYFVU= =p5gv -----END PGP SIGNATURE----- --=-JE8rCjEXJ8wazuw75Pzj-- From pp@ee.oulu.fi Mon Nov 10 14:14:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 14:14:47 -0800 (PST) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAAMEW25000386 for ; Mon, 10 Nov 2003 14:14:34 -0800 Received: from tk28.oulu.fi (tk28 [130.231.48.68]) by ee.oulu.fi (8.12.10/8.12.10) with ESMTP id hAAMEVf2004428 for ; Tue, 11 Nov 2003 00:14:31 +0200 (EET) Received: (from pp@localhost) by tk28.oulu.fi (8.12.10/8.12.10/Submit) id hAAMEU8D026560 for netdev@oss.sgi.com; Tue, 11 Nov 2003 00:14:30 +0200 (EET) Date: Tue, 11 Nov 2003 00:14:30 +0200 From: Pekka Pietikainen To: netdev@oss.sgi.com Subject: Re: [patch] 2.4 lacks dummy SET_NETDEV_DEV Message-ID: <20031110221430.GA26556@ee.oulu.fi> References: <20031110181917.GA25846@ee.oulu.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20031110181917.GA25846@ee.oulu.fi> User-Agent: Mutt/1.4.1i X-archive-position: 1305 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pp@ee.oulu.fi Precedence: bulk X-list: netdev On Mon, Nov 10, 2003 at 08:19:17PM +0200, Pekka Pietikainen wrote: > Just noticed that 2.4 doesn't have a dummy SET_NETDEV_DEV for drivers > written for 2.6 (like the b44 fixes that got merged a few days back, so > it wouldn't actually compile :-) ) Ah, except Jeff merged a version without the call so there should be no problem :-) (I still like the idea of being able to use exactly the same driver source on 2.4/2.6 though) From johnip@sgi.com Mon Nov 10 17:25:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 17:25:33 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAB1Ot25005745 for ; Mon, 10 Nov 2003 17:25:15 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAB1ibHc013388 for ; Mon, 10 Nov 2003 19:44:37 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hAB1OnP513480711; Mon, 10 Nov 2003 19:24:49 -0600 (CST) Received: from sgi.com (fundament.americas.sgi.com [128.162.233.56]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hAB1OaRn345584938; Mon, 10 Nov 2003 19:24:37 -0600 (CST) Message-ID: <3FB03A56.7000709@sgi.com> Date: Mon, 10 Nov 2003 19:24:38 -0600 From: John Partridge Reply-To: johnip@sgi.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031022 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: ak@suse.de, netdev@oss.sgi.com, jgarzik@pobox.com, jes@sgi.com Subject: Re: Tigon3 5701 PCI-X recv performance problem References: <3F844578.40306@sgi.com> <20031008101046.376abc3b.davem@redhat.com> <3F8455BE.8080300@sgi.com> <20031008183742.GA24822@wotan.suse.de> <20031008122223.1ba5ac79.davem@redhat.com> <20031008202248.GA15611@oldwotan.suse.de> <3F8702FF.70500@sgi.com> <20031010192036.GA31727@wotan.suse.de> <3F8802E6.5030601@sgi.com> <20031011131921.GC21763@wotan.suse.de> <20031011105054.0e16a607.davem@redhat.com> <3F8C290A.3010508@sgi.com> <20031014095323.71c8b9fe.davem@redhat.com> In-Reply-To: <20031014095323.71c8b9fe.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1306 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnip@sgi.com Precedence: bulk X-list: netdev I'm working on a patch for the tg3 driver for 2.6 Please can you look at this. I'm not too sure about the Kconfig entry as I have not done one before :- --- linux/drivers/net/tg3.c 2003-11-10 18:28:10.000000000 -0600 +++ patch/drivers/net/tg3.c 2003-11-10 18:58:35.000000000 -0600 @@ -2257,7 +2257,11 @@ len = ((desc->idx_len & RXD_LEN_MASK) >> RXD_LEN_SHIFT) - 4; /* omit crc */ - if (len > RX_COPY_THRESHOLD) { + if (len > RX_COPY_THRESHOLD +#if defined(CONFIG_UNALIGNED_EXPENSIVE) + && tp->rx_offset == 2 +#endif + ) { int skb_size; skb_size = tg3_alloc_rx_skb(tp, opaque_key, --- linux/drivers/net/Kconfig 2003-10-25 13:44:36.000000000 -0500 +++ patch/drivers/net/Kconfig 2003-11-10 19:21:15.000000000 -0600 @@ -2017,6 +2017,9 @@ To compile this driver as a module, choose M here: the module will be called tg3. This is recommended. +config CONFIG_UNALIGNED_EXPENSIVE + bool "Use Aligned SKB's for 5701 cards (for Itanium2 based systems)" + depends on TIGON3 && IA64 endmenu # Thks John -- John Partridge Silicon Graphics Inc Tel: 651-683-3428 Vnet: 233-3428 E-Mail: johnip@sgi.com From davem@pizda.ninka.net Mon Nov 10 18:19:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 18:19:54 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAB2Jd25006487 for ; Mon, 10 Nov 2003 18:19:40 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id SAA15107; Mon, 10 Nov 2003 18:13:19 -0800 Date: Mon, 10 Nov 2003 18:13:19 -0800 From: "David S. Miller" To: francois donzet Cc: netdev@oss.sgi.com Subject: Re: checksum offloading Message-Id: <20031110181319.0a6e0463.davem@redhat.com> In-Reply-To: <20031110112915.3483.qmail@web25201.mail.ukl.yahoo.com> References: <20031110112915.3483.qmail@web25201.mail.ukl.yahoo.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1307 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev I would like to ask that you not send out your questions to all the mailing lists _AND_ privately to every developer you can find an email address for. This is rude and greatly _DECREASES_ the likelyhood that someone will bother to answer your question. Thanks. From davem@pizda.ninka.net Mon Nov 10 18:35:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 18:35:49 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAB2Za25006901 for ; Mon, 10 Nov 2003 18:35:36 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id SAA15160; Mon, 10 Nov 2003 18:29:11 -0800 Date: Mon, 10 Nov 2003 18:29:11 -0800 From: "David S. Miller" To: johnip@sgi.com Cc: ak@suse.de, netdev@oss.sgi.com, jgarzik@pobox.com, jes@sgi.com Subject: Re: Tigon3 5701 PCI-X recv performance problem Message-Id: <20031110182911.2c5a121b.davem@redhat.com> In-Reply-To: <3FB03A56.7000709@sgi.com> References: <3F844578.40306@sgi.com> <20031008101046.376abc3b.davem@redhat.com> <3F8455BE.8080300@sgi.com> <20031008183742.GA24822@wotan.suse.de> <20031008122223.1ba5ac79.davem@redhat.com> <20031008202248.GA15611@oldwotan.suse.de> <3F8702FF.70500@sgi.com> <20031010192036.GA31727@wotan.suse.de> <3F8802E6.5030601@sgi.com> <20031011131921.GC21763@wotan.suse.de> <20031011105054.0e16a607.davem@redhat.com> <3F8C290A.3010508@sgi.com> <20031014095323.71c8b9fe.davem@redhat.com> <3FB03A56.7000709@sgi.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1308 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 10 Nov 2003 19:24:38 -0600 John Partridge wrote: > Please can you look at this. I'm not too sure about the Kconfig entry as I have not done one before :- It belongs in arch/${ARCH}/Kconfig not drivers/net/Kconfig It's a static property of the architecture, not something the user chooses one way or the other. From davem@pizda.ninka.net Mon Nov 10 22:20:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 22:20:48 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAB6KV25012378 for ; Mon, 10 Nov 2003 22:20:33 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id WAA15677; Mon, 10 Nov 2003 22:14:29 -0800 Date: Mon, 10 Nov 2003 22:14:29 -0800 From: "David S. Miller" To: Pekka Pietikainen Cc: netdev@oss.sgi.com Subject: Re: [patch] 2.4 lacks dummy SET_NETDEV_DEV Message-Id: <20031110221429.04732a57.davem@redhat.com> In-Reply-To: <20031110221430.GA26556@ee.oulu.fi> References: <20031110181917.GA25846@ee.oulu.fi> <20031110221430.GA26556@ee.oulu.fi> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1309 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 11 Nov 2003 00:14:30 +0200 Pekka Pietikainen wrote: > (I still like the idea of being able to use exactly the same driver > source on 2.4/2.6 though) I agree, someone should merge in the dummy SET_NETDEV_DEV once Marcelo starts up 2.4.24-preX From davem@pizda.ninka.net Mon Nov 10 22:46:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 22:47:08 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAB6ks25012841 for ; Mon, 10 Nov 2003 22:46:55 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id VAA15643; Mon, 10 Nov 2003 21:46:04 -0800 Date: Mon, 10 Nov 2003 21:46:03 -0800 From: "David S. Miller" To: Jan Oravec Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: IPv6/sparc64: icmp port unreachable corruption Message-Id: <20031110214603.0057e365.davem@redhat.com> In-Reply-To: <20031109122844.GA14241@wsx.ksp.sk> References: <20031109122844.GA14241@wsx.ksp.sk> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1310 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 9 Nov 2003 13:28:44 +0100 Jan Oravec wrote: > We do traceroute6 to 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 (IP of that > sparc64). We get the following corrupted answer: > > 13:17:47.191547 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 > 3ffe:80ee:a:0:201:3ff:fed5:bd1e: [|icmp6] (len 72, hlim 62) > 0x0000 6000 0000 0048 3a3e 3ffe 80ee 03bd 0000 ....H:>?....... > 0x0010 0a00 20ff fec7 a192 3ffe 80ee 000a 0000 ........?....... > 0x0020 0201 03ff fed5 bd1e 0104 aa7c 0000 0000 ...........|.... > 0x0030 0000 0064 0000 0000 0100 0000 0100 0000 ...d............ > 0x0040 aaaa aaaa aaaa aaaa 9680 c00b c622 7fec .............".. > 0x0050 aaaa aaaa aaaa aaaa 9680 c00b c622 7ffc .............".. > 0x0060 aaaa aaaa 0000 0000 8a10 2000 04c2 8049 ...............I What specifically about this packet makes you think it is corrupted? Let's look at the ICMP header you say is "correct" from the x86 box: > 0104 fb79 0000 0000 type = ICMPV6_DEST_UNREACH code = ICMPV6_PORT_UNREACH In the sparc64 generated packet these two values are identical: > 0104 aa7c 0000 0000 So why does tcpdump not say that this is "udp port XXX unreachable" like it does for the x86 generated packet. Incorrect checksum or corrupted payload after the icmp6 header? What compiler are you using to build 2.6.x kernels btw? We could be looking at a miscompile here. The bus error you reported from running traceroute6 on the sparc64 system is not that useful, can you use gdb or some other tool to figure out where inside of tcpdump6 the bus error is occuring? Is is happening in the tcpdump6 program itself? It is due to a failed system call? Thanks. From yoshfuji@linux-ipv6.org Mon Nov 10 23:06:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 23:07:07 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAB76q25013331 for ; Mon, 10 Nov 2003 23:06:52 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-6.6) with ESMTP id hAB76rlg020571; Tue, 11 Nov 2003 16:06:54 +0900 Date: Tue, 11 Nov 2003 01:06:53 -0600 (CST) Message-Id: <20031111.010653.76483304.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: jan.oravec@6com.sk, netdev@oss.sgi.com Subject: Re: IPv6/sparc64: icmp port unreachable corruption From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20031110214603.0057e365.davem@redhat.com> References: <20031109122844.GA14241@wsx.ksp.sk> <20031110214603.0057e365.davem@redhat.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1311 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20031110214603.0057e365.davem@redhat.com> (at Mon, 10 Nov 2003 21:46:03 -0800), "David S. Miller" says: > > 13:17:47.191547 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 > 3ffe:80ee:a:0:201:3ff:fed5:bd1e: [|icmp6] (len 72, hlim 62) > > 0x0000 6000 0000 0048 3a3e 3ffe 80ee 03bd 0000 ....H:>?....... > > 0x0010 0a00 20ff fec7 a192 3ffe 80ee 000a 0000 ........?....... > > 0x0020 0201 03ff fed5 bd1e 0104 aa7c 0000 0000 ...........|.... > > 0x0030 0000 0064 0000 0000 0100 0000 0100 0000 ...d............ > > 0x0040 aaaa aaaa aaaa aaaa 9680 c00b c622 7fec .............".. > > 0x0050 aaaa aaaa aaaa aaaa 9680 c00b c622 7ffc .............".. > > 0x0060 aaaa aaaa 0000 0000 8a10 2000 04c2 8049 ...............I > > What specifically about this packet makes you think it is corrupted? : > So why does tcpdump not say that this is "udp port XXX unreachable" > like it does for the x86 generated packet. > > Incorrect checksum or corrupted payload after the icmp6 header? 0x0030- should be the copy of the original packet. it is corrupted. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@pizda.ninka.net Mon Nov 10 23:08:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 23:08:48 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAB78Y25013669 for ; Mon, 10 Nov 2003 23:08:34 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA15705; Mon, 10 Nov 2003 23:02:33 -0800 Date: Mon, 10 Nov 2003 23:02:33 -0800 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] NET: Normalize jiffies reported to userspace, in neighbor management code Message-Id: <20031110230233.254061da.davem@redhat.com> In-Reply-To: <20031110.104536.79654717.yoshfuji@linux-ipv6.org> References: <20031110.104536.79654717.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1312 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 10 Nov 2003 10:45:36 -0600 (CST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > more jiffies normalizations reported to userspace, in core/neighbour.c. ... > +extern int proc_dointvec_userhz_jiffies(ctl_table *, int, struct file *, > + void __user *, size_t *); This function is huge and it reuses a lot of existing logic. Cannot you implement it simply like this: int proc_dointvec_userhz_jiffies(ctl_table *, int, struct file *, void __user *, size_t *) { return do_proc_dointvec(table,write,filp,buffer,lenp,HZ/USER_HZ,OP_SET); } Right? Linus, what we need here is a function that converts to/from USER_HZ and HZ jiffies for a few sysctl knobs in core/neighbour.c Yoshfuji copied all of the logic of routines such as do_proc_dointvec() replacing the "conv" conversion multiplies and divides with calls to jiffies_to_clock_t() and friends. While this is the cleanest implementation it sure wastes a lot of code for such a minor difference in behavior. Won't my above idea work? Another idea is to change do_proc_dointvec() to take a conversion function pointer instead of this "conv" thing. Maybe even proc_dointvec_minmax() could be implemented in terms of do_proc_dointvec() with such a scheme. From davem@pizda.ninka.net Mon Nov 10 23:09:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 23:10:02 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAB79n25014012 for ; Mon, 10 Nov 2003 23:09:50 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA15733; Mon, 10 Nov 2003 23:03:49 -0800 Date: Mon, 10 Nov 2003 23:03:49 -0800 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] DECNET: Normalize jiffies reported to userspace Message-Id: <20031110230349.693d2fbd.davem@redhat.com> In-Reply-To: <20031110.104843.65576225.yoshfuji@linux-ipv6.org> References: <20031110.104843.65576225.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1313 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 10 Nov 2003 10:48:43 -0600 (CST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > jiffies normalization for decnet. Applied, arigato Yoshfuji. From davem@pizda.ninka.net Mon Nov 10 23:13:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 23:13:32 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAB7DJ25014378 for ; Mon, 10 Nov 2003 23:13:19 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA15755; Mon, 10 Nov 2003 23:07:18 -0800 Date: Mon, 10 Nov 2003 23:07:18 -0800 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPV{4,6}: Normalize jiffies reported to userspace in routing code (missing pieces) Message-Id: <20031110230718.5edf31c9.davem@redhat.com> In-Reply-To: <20031110.105023.116811039.yoshfuji@linux-ipv6.org> References: <20031110.105023.116811039.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1314 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 10 Nov 2003 10:50:23 -0600 (CST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > Sorry, I failed to fix these bits. Applied, thank you very much. From davem@pizda.ninka.net Mon Nov 10 23:18:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 23:18:55 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAB7Ig25014811 for ; Mon, 10 Nov 2003 23:18:42 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA15768; Mon, 10 Nov 2003 23:12:38 -0800 Date: Mon, 10 Nov 2003 23:12:38 -0800 From: "David S. Miller" To: "Ihar 'Philips' Filipau" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: net/packet/af_packet.c:{1057,1073}: flags vs. msg->flags Message-Id: <20031110231238.4742a158.davem@redhat.com> In-Reply-To: <3FAF7236.7020209@softhome.net> References: <3FAF7236.7020209@softhome.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1315 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 10 Nov 2003 12:10:46 +0100 "Ihar 'Philips' Filipau" wrote: > On line 1057 we have: "msg->msg_flags|=MSG_TRUNC;" to indicate that > message was truncated. > > But on line 1073, where we make return status to user, we check > against user suplied flags, but NOT msg->msg_flags. > > It looks like obvious typo. Indeed, you're right. Thanks for the report, I'll fix this in both 2.4.x and 2.6.x From ja@ssi.bg Mon Nov 10 23:29:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Nov 2003 23:30:05 -0800 (PST) Received: from u.domain.uli (ja.mac.ssi.bg [217.79.71.194]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAB7Tb25015249 for ; Mon, 10 Nov 2003 23:29:41 -0800 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.6/8.11.6) with ESMTP id hAB7TJx01181; Tue, 11 Nov 2003 09:29:25 +0200 Date: Tue, 11 Nov 2003 09:29:19 +0200 (EET) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: netdev@oss.sgi.com cc: "David S. Miller" , Wensong Zhang Subject: [2.6 PATCH] ipvs - make sure the timer expires on one cpu Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1607745702-419511311-1068535759=:1155" X-archive-position: 1316 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1607745702-419511311-1068535759=:1155 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, The attached patch fixes the timer expiration for IPVS. The goal is to avoid scheduling of running timer on another CPU in short time (jiffie), ip_vs_conn_expire must run only on one CPU at time per conn. Regards -- Julian Anastasov --1607745702-419511311-1068535759=:1155 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="timer-1.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: ipvs timer fix Content-Disposition: attachment; filename="timer-1.diff" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTM0OCAgLT4gMS4xMzQ5IA0KIwlu ZXQvaXB2NC9pcHZzL2lwX3ZzX2Nvbm4uYwkxLjExICAgIC0+IDEuMTIgICAN CiMNCiMgVGhlIGZvbGxvd2luZyBpcyB0aGUgQml0S2VlcGVyIENoYW5nZVNl dCBMb2cNCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCiMgMDMvMTEvMTEJamFAc3NpLmJnCTEuMTM0OQ0KIyBbSVBW U106IG1ha2Ugc3VyZSB0aGUgdGltZXIgZXhwaXJlcyBvbiBvbmUgY3B1DQoj IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQojDQpkaWZmIC1OcnUgYS9uZXQvaXB2NC9pcHZzL2lwX3ZzX2Nvbm4uYyBi L25ldC9pcHY0L2lwdnMvaXBfdnNfY29ubi5jDQotLS0gYS9uZXQvaXB2NC9p cHZzL2lwX3ZzX2Nvbm4uYwlUdWUgTm92IDExIDA4OjUyOjE2IDIwMDMNCisr KyBiL25ldC9pcHY0L2lwdnMvaXBfdnNfY29ubi5jCVR1ZSBOb3YgMTEgMDg6 NTI6MTYgMjAwMw0KQEAgLTUzNSw4ICs1MzUsMTAgQEANCiANCiB2b2lkIGlw X3ZzX2Nvbm5fZXhwaXJlX25vdyhzdHJ1Y3QgaXBfdnNfY29ubiAqY3ApDQog ew0KLQljcC0+dGltZW91dCA9IDA7DQotCW1vZF90aW1lcigmY3AtPnRpbWVy LCBqaWZmaWVzKTsNCisJaWYgKGRlbF90aW1lcigmY3AtPnRpbWVyKSkgew0K KwkJY3AtPnRpbWVvdXQgPSAwOw0KKwkJbW9kX3RpbWVyKCZjcC0+dGltZXIs IGppZmZpZXMpOw0KKwl9DQogCV9faXBfdnNfY29ubl9wdXQoY3ApOw0KIH0N CiANCg== --1607745702-419511311-1068535759=:1155-- From ja@ssi.bg Tue Nov 11 00:07:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 11 Nov 2003 00:07:59 -0800 (PST) Received: from u.domain.uli (ja.mac.ssi.bg [217.79.71.194]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAB87K25016075 for ; Tue, 11 Nov 2003 00:07:39 -0800 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.6/8.11.6) with ESMTP id hAB87HO01729; Tue, 11 Nov 2003 10:07:17 +0200 Date: Tue, 11 Nov 2003 10:07:17 +0200 (EET) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: netdev@oss.sgi.com cc: "David S. Miller" , Wensong Zhang Subject: Re: [2.6 PATCH] ipvs - make sure the timer expires on one cpu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1607745702-1832032584-1068538037=:1176" X-archive-position: 1317 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1607745702-1832032584-1068538037=:1176 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, Ah, sorry. It is bad idea to set cp->timeout to 0. Please, better use the attached patch instead. Regards -- Julian Anastasov --1607745702-1832032584-1068538037=:1176 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="timer-2.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: fix ipvs timer, v2 Content-Disposition: attachment; filename="timer-2.diff" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTM0OCAgLT4gMS4xMzQ5IA0KIwlu ZXQvaXB2NC9pcHZzL2lwX3ZzX2Nvbm4uYwkxLjExICAgIC0+IDEuMTIgICAN CiMNCiMgVGhlIGZvbGxvd2luZyBpcyB0aGUgQml0S2VlcGVyIENoYW5nZVNl dCBMb2cNCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCiMgMDMvMTEvMTEJamFAc3NpLmJnCTEuMTM0OQ0KIyBbSVBW U106IG1ha2Ugc3VyZSB0aGUgdGltZXIgZXhwaXJlcyBvbiBvbmUgY3B1DQoj IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQojDQpkaWZmIC1OcnUgYS9uZXQvaXB2NC9pcHZzL2lwX3ZzX2Nvbm4uYyBi L25ldC9pcHY0L2lwdnMvaXBfdnNfY29ubi5jDQotLS0gYS9uZXQvaXB2NC9p cHZzL2lwX3ZzX2Nvbm4uYwlUdWUgTm92IDExIDEwOjA0OjE4IDIwMDMNCisr KyBiL25ldC9pcHY0L2lwdnMvaXBfdnNfY29ubi5jCVR1ZSBOb3YgMTEgMTA6 MDQ6MTggMjAwMw0KQEAgLTUzNSw4ICs1MzUsOCBAQA0KIA0KIHZvaWQgaXBf dnNfY29ubl9leHBpcmVfbm93KHN0cnVjdCBpcF92c19jb25uICpjcCkNCiB7 DQotCWNwLT50aW1lb3V0ID0gMDsNCi0JbW9kX3RpbWVyKCZjcC0+dGltZXIs IGppZmZpZXMpOw0KKwlpZiAoZGVsX3RpbWVyKCZjcC0+dGltZXIpKQ0KKwkJ bW9kX3RpbWVyKCZjcC0+dGltZXIsIGppZmZpZXMpOw0KIAlfX2lwX3ZzX2Nv bm5fcHV0KGNwKTsNCiB9DQogDQo= --1607745702-1832032584-1068538037=:1176-- From amir.noam@intel.com Tue Nov 11 02:32:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 11 Nov 2003 02:32:36 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hABAW925021355 for ; Tue, 11 Nov 2003 02:32:13 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hABAW3YX016677 for ; Tue, 11 Nov 2003 10:32:03 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hABAZJI26839 for ; Tue, 11 Nov 2003 10:35:19 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003111112320224340 ; Tue, 11 Nov 2003 12:32:02 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.254.188]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id hABAVxFo027278; Tue, 11 Nov 2003 12:32:00 +0200 (IST) Content-Type: text/plain; charset="us-ascii" From: Amir Noam To: jgarzik@pobox.com, davem@redhat.com Subject: [PATCH] [bonding 2.4] fix creating/destroying the /proc/net/bonding dir Date: Tue, 11 Nov 2003 12:32:01 +0200 User-Agent: KMail/1.4.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200311111232.01428.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 1318 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Hi, Since 2.4.23-rc1 is out, I'm resending this patch that fixes a problem in the creation/destruction of the /proc/net/bonding dir, introduced in 2.4.23-pre5. Please apply. Amir diff -Narup a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Thu Oct 23 14:47:31 2003 +++ b/drivers/net/bonding/bond_main.c Thu Oct 23 17:04:52 2003 @@ -3574,6 +3574,62 @@ static void bond_destroy_proc_info(struc bond->bond_proc_file = NULL; } } + +/* Create the bonding directory under /proc/net, if doesn't exist yet. + * Caller must hold rtnl_lock. + */ +static void bond_create_proc_dir(void) +{ + int len = strlen(DRV_NAME); + + for (bond_proc_dir = proc_net->subdir; bond_proc_dir; + bond_proc_dir = bond_proc_dir->next) { + if ((bond_proc_dir->namelen == len) && + !memcmp(bond_proc_dir->name, DRV_NAME, len)) { + break; + } + } + + if (!bond_proc_dir) { + bond_proc_dir = proc_mkdir(DRV_NAME, proc_net); + if (bond_proc_dir) { + bond_proc_dir->owner = THIS_MODULE; + } else { + printk(KERN_WARNING DRV_NAME + ": Warning: cannot create /proc/net/%s\n", + DRV_NAME); + } + } +} + +/* Destroy the bonding directory under /proc/net, if empty. + * Caller must hold rtnl_lock. + */ +static void bond_destroy_proc_dir(void) +{ + struct proc_dir_entry *de; + + if (!bond_proc_dir) { + return; + } + + /* verify that the /proc dir is empty */ + for (de = bond_proc_dir->subdir; de; de = de->next) { + /* ignore . and .. */ + if (*(de->name) != '.') { + break; + } + } + + if (de) { + if (bond_proc_dir->owner == THIS_MODULE) { + bond_proc_dir->owner = NULL; + } + } else { + remove_proc_entry(DRV_NAME, proc_net); + bond_proc_dir = NULL; + } +} #endif /* CONFIG_PROC_FS */ /* @@ -3829,6 +3885,9 @@ static struct notifier_block bond_netdev .notifier_call = bond_netdev_event, }; +/* De-initialize device specific data. + * Caller must hold rtnl_lock. + */ static inline void bond_deinit(struct net_device *dev) { struct bonding *bond = dev->priv; @@ -3840,6 +3899,9 @@ static inline void bond_deinit(struct ne #endif } +/* Unregister and free all bond devices. + * Caller must hold rtnl_lock. + */ static void bond_free_all(void) { struct bonding *bond, *nxt; @@ -3847,16 +3909,13 @@ static void bond_free_all(void) list_for_each_entry_safe(bond, nxt, &bond_dev_list, bond_list) { struct net_device *dev = bond->device; - unregister_netdev(dev); + unregister_netdevice(dev); bond_deinit(dev); free_netdev(dev); } #ifdef CONFIG_PROC_FS - if (bond_proc_dir) { - remove_proc_entry(DRV_NAME, proc_net); - bond_proc_dir = NULL; - } + bond_destroy_proc_dir(); #endif } @@ -4234,18 +4293,12 @@ static int __init bonding_init(void) primary = NULL; } + rtnl_lock(); + #ifdef CONFIG_PROC_FS - bond_proc_dir = proc_mkdir(DRV_NAME, proc_net); - if (bond_proc_dir == NULL) { - printk(KERN_WARNING - "bonding_init(): can not create /proc/net/" DRV_NAME); - } else { - bond_proc_dir->owner = THIS_MODULE; - } + bond_create_proc_dir(); #endif - rtnl_lock(); - err = 0; for (no = 0; no < max_bonds; no++) { struct net_device *dev; @@ -4288,18 +4341,21 @@ static int __init bonding_init(void) return 0; out_err: - rtnl_unlock(); - /* free and unregister all bonds that were successfully added */ bond_free_all(); + rtnl_unlock(); + return err; } static void __exit bonding_exit(void) { unregister_netdevice_notifier(&bond_netdev_notifier); + + rtnl_lock(); bond_free_all(); + rtnl_unlock(); } module_init(bonding_init); From torvalds@osdl.org Tue Nov 11 09:03:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 11 Nov 2003 09:04:14 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hABH3x25012579 for ; Tue, 11 Nov 2003 09:03:59 -0800 Received: from localhost (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id hABH3qC22725 for ; Tue, 11 Nov 2003 09:03:53 -0800 X-Received: from localhost (localhost.localdomain [127.0.0.1]) by home.osdl.org (8.12.10/8.12.10) with ESMTP id hABGtmXK006671 for ; Tue, 11 Nov 2003 08:55:48 -0800 X-Received: from localhost.localdomain [127.0.0.1] by localhost with IMAP (fetchmail-6.2.0) for torvalds@localhost (single-drop); Tue, 11 Nov 2003 08:55:48 -0800 (PST) X-Received: from fire-1.osdl.org (air1.pdx.osdl.net [172.20.0.5]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id hABGtWC20841 for ; Tue, 11 Nov 2003 08:55:32 -0800 X-Received: from vger.kernel.org (vger.kernel.org [67.72.78.212]) by fire-1.osdl.org (8.12.8/8.12.8) with ESMTP id hABGt718001147 for ; Tue, 11 Nov 2003 08:55:31 -0800 X-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263667AbTKKQn4 (ORCPT ); Tue, 11 Nov 2003 11:43:56 -0500 X-Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263680AbTKKQn4 (ORCPT ); Tue, 11 Nov 2003 11:43:56 -0500 X-Received: from theendless.org ([216.251.47.14]:20167 "EHLO morpheus.theendless.org") by vger.kernel.org with ESMTP id S263667AbTKKQnn (ORCPT ); Tue, 11 Nov 2003 11:43:43 -0500 X-Received: from localhost (localhost [127.0.0.1]) by morpheus.theendless.org (8.12.9/8.12.2) with ESMTP id hABGhgfi008132 for ; Tue, 11 Nov 2003 11:43:42 -0500 Date: Tue, 11 Nov 2003 11:43:42 -0500 (EST) From: morpheus To: linux-kernel@vger.kernel.org Subject: linux-2.6.0-test9 and IPVS (Kernel OOPS) with sync daemon started. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-Scanned-By: MIMEDefang 2.36 ReSent-Date: Tue, 11 Nov 2003 09:03:50 -0800 (PST) ReSent-From: Linus Torvalds ReSent-To: netdev@oss.sgi.com ReSent-Subject: linux-2.6.0-test9 and IPVS (Kernel OOPS) with sync daemon started. ReSent-Message-ID: X-archive-position: 1319 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: torvalds@osdl.org Precedence: bulk X-list: netdev Hi, Being my first post to the list I hope all the information included is as accurate and detailed as possible. Feedback is greatly appreciated, thanks in advance. SUMMARY: I seem to have found a problem with the linux-2.6.0-test9 kernel and the Sync daemon that comes with IPVS. I can reproduce the problem without fail and it produces a kernel OOPS every time. PROBLEM REPORT: The setup is as follows. 2 hardware identical linux machines are functioning as directors in an IPVS setup. One is master and the other backup. I have successfully implemented failover on these servers. However, when attempting to use the stateful failover option in ipvsadm (IPVS) by running "ipvsadm --start-daemon master" on the master and "ipvsadm --start-daemon slave" on the slave and failing the connection over, the kernel on the slave machine craps out. It produces an oops which is posted (after processing via ksymoops) below. It seems to happen at the exact moment that the slave machine takes over the virtual ip's that the master machine owned, ie. right after gratiuitous arps are sent out to make sure everyone knows where the new ips are. Keep in mind that the slave machine does NOT take over the main IP's of the primary director, as this may lead to some networking issues which should still not cause an OOps. If I do not enable the sync-daemon (ie. NO stateful failover), everything keeps on trudging along as normal. KERNEL VERSION: Linux version 2.6.0-test9 (root@director1) (gcc version 3.2) #1 SMP Sat Feb 7 21:38:27 EST 2004 OOPS OUTPUT (ksymoops processed): Oops: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000010 ebx: f7022880 ecx: f7022880 edx: 00000010 esi: 00000000 edi: f76e9d80 ebp: 00000010 esp: c0389d2c ds: 007b es: 007b ss: 0068 Stack: c0389d48 c1b41000 00000000 c02c8975 c0353900 c0389d48 f70b500c f733be20 f77ec680 c0353900 00000036 00000000 00000000 f76e9d80 c0354840 f7022880 c02d9ec5 f76e9d80 00000014 c0389dd0 00000014 c02cd3ad 00000006 5601a8c0 [] fib_validate_source+0x1f5/0x296 [] tcp_state_transition+0x3f/0x2d6 [] ip_vs_conn_in_get+0xad/0x26e [] ip_vs_dr_xmit+0x0/0x744 [] ip_local_deliver_finish+0x0/0x162 [] ip_vs_in+0x185/0x304 [] nf_iterate+0x71/0xa6 [] ip_local_deliver_finish+0x0/0x162 [] nf_hook_slow+0x79/0x124 [] ip_local_deliver_finish+0x0/0x162 [] ip_local_deliver+0x1b7/0x1d6 [] ip_local_deliver_finish+0x0/0x162 [] ip_rcv+0x360/0x4d8 [] netif_receive_skb+0x13f/0x17a [] process_backlog+0x80/0x112 [] net_rx_action+0x7a/0x104 [] do_softirq+0xc3/0xc6 [] do_IRQ+0xf6/0x114 [] default_idle+0x0/0x2e [] common_interrupt+0x18/0x20 [] default_idle+0x0/0x2e [] default_idle+0x2a/0x2e [] cpu_idle+0x37/0x40 [] _stext+0x0/0x52 [] start_kernel+0x194/0x1c2 [] unknown_bootoption+0x0/0xfc Code: a1 10 00 00 00 c7 44 24 4c 00 00 00 00 88 94 24 8