From davem@pizda.ninka.net Wed Oct 1 00:09:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 00:10:05 -0700 (PDT) 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 h9179NFx029468 for ; Wed, 1 Oct 2003 00:09:23 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA05395; Wed, 1 Oct 2003 00:05:24 -0700 Date: Wed, 1 Oct 2003 00:05:24 -0700 From: "David S. Miller" To: "Chad N. Tindel" Cc: fubar@us.ibm.com, shmulik.hen@intel.com, jgarzik@pobox.com, chad@tindel.net, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] Re: [bonding] compatibilty issues Message-Id: <20031001000524.7e0d851e.davem@redhat.com> In-Reply-To: <20030930213650.GA71877@calma.pair.com> References: <200309301442.31991.shmulik.hen@intel.com> <200309301639.h8UGdqCq026858@death.ibm.com> <20030930213650.GA71877@calma.pair.com> X-Mailer: Sylpheed version 0.9.2 (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: 422 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, 30 Sep 2003 17:36:50 -0400 "Chad N. Tindel" wrote: > My recommendations are more towards the middle than either end. I would > like to see us get rid of the _OLD ioctls in the 2.6 kernel specifically > because it uses the SIOCDEVPRIVATE ioctls. ... > I would like to see them stay in 2.4 for the rest of the 2.4 tree > specifically so that people who want to run on 3 year old systems > can continue to do so without us breaking their world. I think this is fine, personally. I defer to Jeff for final judgment, he should be allowed to chime in at least once more. From davem@pizda.ninka.net Wed Oct 1 00:12:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 00:12:42 -0700 (PDT) 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 h917C4Fx029964 for ; Wed, 1 Oct 2003 00:12:04 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA05410; Wed, 1 Oct 2003 00:07:04 -0700 Date: Wed, 1 Oct 2003 00:07:04 -0700 From: "David S. Miller" To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, shemminger@osdl.org, netdev@oss.sgi.com, irda-users@lists.sourceforge.net Subject: Re: [PATCH] (0/16) intro to IRDA patches for 2.6.0-test6 Message-Id: <20031001000704.252e4737.davem@redhat.com> In-Reply-To: <20030930230049.GA22339@bougret.hpl.hp.com> References: <20030930152530.1e279c29.shemminger@osdl.org> <20030930230049.GA22339@bougret.hpl.hp.com> X-Mailer: Sylpheed version 0.9.2 (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: 423 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, 30 Sep 2003 16:00:49 -0700 Jean Tourrilhes wrote: > On Tue, Sep 30, 2003 at 03:25:30PM -0700, Stephen Hemminger wrote: > > David, please apply after Jean gives his approval. ... > Please go ahead, I'll test them in parallel. > Thanks ! Great, I'm applying Stephen's patches now. From linux-netdev@gmane.org Wed Oct 1 01:02:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 01:03:20 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9182MFx004243 for ; Wed, 1 Oct 2003 01:02:43 -0700 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1A4bwC-00015B-00 for ; Wed, 01 Oct 2003 10:02:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1A4bwB-000151-00 for ; Wed, 01 Oct 2003 10:02:19 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1A4bwA-0008AU-00 for ; Wed, 01 Oct 2003 10:02:18 +0200 From: Florian Zwoch Subject: Re: e1000 -> 82540EM on linux 2.6.0-test[45] very slow in one direction Date: Wed, 01 Oct 2003 10:02:18 +0200 Lines: 59 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030909 Thunderbird/0.2 X-Accept-Language: en-us, en In-Reply-To: Cc: linux-kernel@vger.kernel.org X-archive-position: 424 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zwoch@backendmedia.com Precedence: bulk X-list: netdev issue seems to partly solved. the e1000 driver seems to be ok! i reconfigured my kernel and intentionally left out netfilter options. after that my network performance was back to normal. netfilter was only compiled in the kernel. it was not used with any rules! so my wild guess would be that something with the netfilter code (i am not 100% sure it was netfilter.. _maybe_ it was some small odd kernel option i accidently enabled/disabled) is broken since test3 (again uncertified. but i firstly noticed this switching from test3 to test4). Florian Zwoch wrote: > hi, > this has been discussed very roughly before. but unfortunately no real > solution has been brought up so far (or i have not read it yet). > > problem in short: the 82540EM intel gigabit adapter became very slow as > of 2.6.0-test4. maybe earlier versions were als affected aswell, but i > noticed this behaviour on test4 and later. the 'slowness' of the adapter > only affects a certain data direction. i performed the following tests > to show you what is wrong. > > dummy data file was 34257856 bytes (34.3MB). > test machines were a pentium4 with the intel adapter, and a pentium2 266 > with a lowcost realtek card (runs linux 2.4). > > SCP: > e1000 -> 8139too 28.6KB/s > e1000 <- 8139too 4.6MB/s > > SMB: > e1000 -> 8139too 3.0MB/s > e1000 <- 8139too 3.3MB/s > > FTP > e1000 -> 8139too 54KB/s > e1000 <- 8139too 9.4MB/s > > as you can see reveiving data is no problem at all (maybe another > protocol can create some problems in this case?). but sending data is > awesome slow! exception is the samba protocol. why is that? i thought > that samba may use udp instead of tcp. but iptraf did not show any udp > packets going around so i guess i was wrong. > > the problem gets worse while trying to test things over the internet. > scp stalls incredibly often on my 256kbit/s upstream. so does ftp and > irc dcc protocol. irc dcc ends up with sending 0.3KB/s on a megabyte > sized file. > > before people again trying to tell me that some duplex settings could be > messed up - then tell me why this should happen. when i boot into 2.4 > kernel with that test machine the nic works without problems. so IF > duplex stuff is the reason for the hickups something must be wrong with > the duplex detection code in the new driver/kernel? > > i tried vanilla 2.6.0-test5, 2.6.0-test5-mm2 and mm3 + 2.6.0-test5-bk4. > none of these gave any difference regarding network performance. From scott.feldman@intel.com Wed Oct 1 01:19:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 01:20:23 -0700 (PDT) Received: from hermes.hd.intel.com (fmr09.intel.com [192.52.57.35]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h918JmFx005756 for ; Wed, 1 Oct 2003 01:19:49 -0700 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6-20030918-01/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h918HK423372 for ; Wed, 1 Oct 2003 08:17:20 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.hd.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 h918EGj09441 for ; Wed, 1 Oct 2003 08:14:16 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003100101194211202 ; Wed, 01 Oct 2003 01:19:42 -0700 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 1 Oct 2003 01:19:41 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Fw: Badness in local_bh_enable at kernel/softirq.c:119 Date: Wed, 1 Oct 2003 01:19:41 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fw: Badness in local_bh_enable at kernel/softirq.c:119 Thread-Index: AcOH6PnqvodJajp4QQ2HBr81WTDsWgABV2CQ From: "Feldman, Scott" To: "David S. Miller" Cc: , , , "cramerj" X-OriginalArrivalTime: 01 Oct 2003 08:19:41.0980 (UTC) FILETIME=[C39815C0:01C387F4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h918JmFx005756 X-archive-position: 425 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev > Why do you even need to use IRQ locking here? > > Your e1000 netdev->hard_start_xmit method doesn't need to do > anything special, why does this timer code? I suppose you > need to synchronize with e1000_clean_tx_irq() in the non-NAPI > case right? If so, that's not being accomplished by what > your code is doing. If nobody else takes that xmit_lock in > an IRQ disabling manner, the e1000 timer code doing so > doesn't make any difference. > > I have an idea for attacking the problem, once you figure out > what kind of locking you really need. Do whatever you need > to do to synchronize on the hardware side, but instead of > directly freeing the SKB, add each one to a list. A pointer > to the head of this list is stored on the stack of the timer > routine, and passed down into the TX purger. > > Then at the top level you can drop all your locks, re-enable > hw IRQs and whatever else you need to do, then pass the SKBs > in the list off to dev_kfree_skb_irq() (this is the > appropriate routine to call to free an SKB from a timer > handler, which runs in soft interrupt context). Chris can jump in here anytime. :-) Synchronizing on the hardware side is stumping me. We have the list of skbs you describe, but I'm concerned about unmapping the skb buffers if hardware is right in the middle of some DMA on one of the buffers. Some archs really don't like hardware accessing unmapped buffers. Here's what I'm thinking: when link down is detected in the timer, just trick hardware into thinking link is still up (ILOS - Invert Loss of Signal). No locking, no disabling of interrupts. Hardware will do the natural thing by completing the outstanding sends and also provide the interrupts so we can clean/return skbs as normal (e1000_clean_tx_irq). Something like: if lost link if outstanding Tx work set ILOS // h/w thinks link is up, DMA continues mdelay(10) clear ILOS // h/w thinks link is down The mdelay(10) is terrible, but we've already got that in the current tx_flush routine. Chris, what am I missing? I didn't included the ANE business for clarity. -scott From davem@pizda.ninka.net Wed Oct 1 01:41:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 01:41:44 -0700 (PDT) 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 h918fAFx007693 for ; Wed, 1 Oct 2003 01:41:10 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id BAA05942; Wed, 1 Oct 2003 01:37:10 -0700 Date: Wed, 1 Oct 2003 01:37:10 -0700 From: "David S. Miller" To: "Feldman, Scott" Cc: jgarzik@pobox.com, akpm@osdl.org, netdev@oss.sgi.com, cramerj@intel.com Subject: Re: Fw: Badness in local_bh_enable at kernel/softirq.c:119 Message-Id: <20031001013710.425038fd.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (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: 426 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, 1 Oct 2003 01:19:41 -0700 "Feldman, Scott" wrote: > Synchronizing on the hardware side is stumping me. We have the list of > skbs you describe, but I'm concerned about unmapping the skb buffers if > hardware is right in the middle of some DMA on one of the buffers. > Some archs really don't like hardware accessing unmapped buffers. Good point, if the e1000 accesses the DMA buffer after the unmap it will cause many arch's to signal PCI errors since the IOMMU will no longer have a valid translation for those DMA requests. > Here's what I'm thinking: when link down is detected in the timer, just > trick hardware into thinking link is still up (ILOS - Invert Loss of > Signal). No locking, no disabling of interrupts. Hardware will do the > natural thing by completing the outstanding sends and also provide the > interrupts so we can clean/return skbs as normal (e1000_clean_tx_irq). If you can make that work, it's the simplest fix. From shmulik.hen@intel.com Wed Oct 1 01:49:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 01:49:54 -0700 (PDT) Received: from hermes.hd.intel.com (fmr09.intel.com [192.52.57.35]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h918nHFx009002 for ; Wed, 1 Oct 2003 01:49:18 -0700 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6-20030918-01/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h918kn428879 for ; Wed, 1 Oct 2003 08:46:49 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.hd.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 h918hjj15997 for ; Wed, 1 Oct 2003 08:43:45 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003100101490517770 ; Wed, 01 Oct 2003 01:49:07 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: "David S. Miller" , "Chad N. Tindel" , , Subject: Re: [Bonding-devel] Re: [bonding] compatibilty issues Date: Wed, 1 Oct 2003 11:49:04 +0300 User-Agent: KMail/1.4.3 Cc: , References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200310011149.04612.shmulik.hen@intel.com> X-archive-position: 427 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev On Wednesday 01 October 2003 10:05 am, David S. Miller wrote: > On Tue, 30 Sep 2003 17:36:50 -0400 > > "Chad N. Tindel" wrote: > > My recommendations are more towards the middle than either end. > > I would like to see us get rid of the _OLD ioctls in the 2.6 > > kernel specifically because it uses the SIOCDEVPRIVATE ioctls. > > ... > > > I would like to see them stay in 2.4 for the rest of the 2.4 tree > > specifically so that people who want to run on 3 year old systems > > can continue to do so without us breaking their world. > > I think this is fine, personally. > > I defer to Jeff for final judgment, he should be allowed to chime > in at least once more. > So here is what I did in the meantime: * Created a version for 2.4 that puts back all old compatibility stuff that was removed either during the propagation set or the cleanup set. * Created a version for 2.6 that puts back just the compatibility stuff that was removed in the propagation set (BOND_SETHWADDR, since we got a complaint from a RH9 user). * Removed the mention of the multicast param from the read-me. * Raised the ABI version to 2 so the new ifenslave keeps propagating IP settings to slaves for older drivers, and doesn't do that for new ones that contain Willy Tarreau's panic fix. As for not putting new stuff in 2.4.x kernels, here is where we stand; We believe new distributions based on 2.4.x kernels will keep showing for at least a year, probably longer, and that customers would like to see more bonding features in those distributions, so our intention is to keep getting new stuff into 2.4. We understand the drive to put new stuff into 2.6 and backport to 2.4 from time to time, but we'll really need to keep doing stuff the current way for a while. The cleanup stuff came up as a necessity before developing the next set of features, and those are all based on a cleaned-up bonding, so delaying the acceptance of the cleanup into 2.4 also delays our features acceptance. I'm waiting for the final word from everyone. I'll need to test the two new versions, but then I can release them accordingly. -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From andi@averellmail.firstfloor.org Wed Oct 1 05:12:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 05:13:09 -0700 (PDT) Received: from zero.aec.at (Fogarty.Weffing@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91CCXFx030504 for ; Wed, 1 Oct 2003 05:12:34 -0700 Received: from fred.muc.de (Atka.Mip@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id h91CCPS09724; Wed, 1 Oct 2003 14:12:26 +0200 Received: by fred.muc.de (Postfix on SuSE Linux 7.3 (i386), from userid 500) id C6DD15BBEE; Wed, 1 Oct 2003 14:12:26 +0200 (CEST) Date: Wed, 1 Oct 2003 14:12:26 +0200 From: Andi Kleen To: netdev@oss.sgi.com Cc: mingo@redhat.com Subject: [PATCH] Fix ppro csum_partial for 1 byte unaligned buffers Message-ID: <20031001121226.GA11676@averell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 429 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 2003 Lines: 78 When using sendfile it can happen that csum_partial is called for memory areas that are not aligned to a 2 byte boundary. The ppro optimized i386 checksum code handled this slowly, but read upto 3 bytes over the end of the buffer. When the skb contents are mapped from highmem this can be fatal because the end of the buffer can be unmapped. This patch fixes this in a simple non intrusive way by handling the possible fault and recovering from it by using a tolerant byte-by-byte copy. It does not attempt to align one byte unaligned buffers, because that's rather complicated and probably not worth the effort. Other architectures may want to audit their csum_partial if it handles this case correctly. Bug is in 2.4 and 2.6 -Andi diff -u linux/arch/i386/lib/checksum.S-o linux/arch/i386/lib/checksum.S --- linux/arch/i386/lib/checksum.S-o 2003-03-07 16:48:01.000000000 +0100 +++ linux/arch/i386/lib/checksum.S 2003-10-01 14:01:31.000000000 +0200 @@ -48,6 +48,9 @@ * least a twofold speedup on 486 and Pentium if it is 4-byte aligned. * Fortunately, it is easy to convert 2-byte alignment to 4-byte * alignment for the unrolled loop. + * + * Danger, Will Robinson: with sendfile 2 byte alignment is not guaranteed. + * */ csum_partial: pushl %esi @@ -237,18 +240,37 @@ movl $0xffffff,%ebx # by the shll and shrl instructions shll $3,%ecx shrl %cl,%ebx - andl -128(%esi),%ebx # esi is 4-aligned so should be ok +.Ltail: + andl -128(%esi),%ebx +.Ttail_finished addl %ebx,%eax adcl $0,%eax 80: testl $1, 12(%esp) jz 90f roll $8, %eax -90: +90: popl %ebx popl %esi ret - + + .section __ex_table,"a" + .long .Ltail,tail_recover + .long .Ltail_byte3,.Ltail_byte1 + .long .Ltail_byte2,.Ltail_finished + .previous + +tail_recover: + xorl %ebx,%ebx +.Ltail_byte3: + movb -126(%esi),%bl + shl $16,%ebx +.Ltail_byte1: + movb -128(%esi),%bl +.Ltail_byte2: + movb -127(%esi),%bh + jmp .Ltailfinished + #endif /* From chas@cmf.nrl.navy.mil Wed Oct 1 05:17:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 05:17:54 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91CHKFx030849 for ; Wed, 1 Oct 2003 05:17:21 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id h91BYPkT003172 for ; Wed, 1 Oct 2003 07:34:25 -0400 (EDT) Message-Id: <200310011134.h91BYPkT003172@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Subject: [RFC] add rtnl semaphore to linux-atm Reply-To: chas3@users.sourceforge.net Date: Wed, 01 Oct 2003 07:34:25 -0400 From: chas williams X-Spam-Score: () hits=0.5 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 430 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 9239 Lines: 360 i am thinking about doing the following to fix the race during ATM_ITF_ANY operation. rtnl is held across registration/unregistration. this means that you can get read-only access to the device list by holding rtnl or a read_lock on atm_dev_lock similar to the scheme used by netdevice (or so i think). (the register_atmdevice/unregister just make it easier to see where one might call netdevice instead in the future) ===== drivers/atm/atmtcp.c 1.20 vs edited ===== --- 1.20/drivers/atm/atmtcp.c Tue Sep 23 19:22:15 2003 +++ edited/drivers/atm/atmtcp.c Mon Sep 29 21:34:36 2003 @@ -378,7 +378,7 @@ struct atm_dev *dev; dev = NULL; - if (itf != -1) dev = atm_dev_lookup(itf); + if (itf != -1) dev = atm_dev_get_by_index(itf); if (dev) { if (dev->ops != &atmtcp_v_dev_ops) { atm_dev_put(dev); @@ -415,7 +415,7 @@ struct atm_dev *dev; struct atmtcp_dev_data *dev_data; - dev = atm_dev_lookup(itf); + dev = atm_dev_get_by_index(itf); if (!dev) return -ENODEV; if (dev->ops != &atmtcp_v_dev_ops) { atm_dev_put(dev); ===== include/linux/atmdev.h 1.32 vs edited ===== --- 1.32/include/linux/atmdev.h Tue Sep 23 18:19:10 2003 +++ edited/include/linux/atmdev.h Mon Sep 29 21:59:18 2003 @@ -388,7 +388,7 @@ struct atm_dev *atm_dev_register(const char *type,const struct atmdev_ops *ops, int number,unsigned long *flags); /* number == -1: pick first available */ -struct atm_dev *atm_dev_lookup(int number); +struct atm_dev *atm_dev_get_by_index(int ifindex); void atm_dev_deregister(struct atm_dev *dev); void shutdown_atm_dev(struct atm_dev *dev); void vcc_insert_socket(struct sock *sk); @@ -435,11 +435,12 @@ { atomic_dec(&dev->refcnt); - if ((atomic_read(&dev->refcnt) == 1) && + if ((atomic_read(&dev->refcnt) == 0) && test_bit(ATM_DF_CLOSE,&dev->flags)) shutdown_atm_dev(dev); } +#define __atm_dev_put(dev) atomic_dec(&(dev)->refcnt) int atm_charge(struct atm_vcc *vcc,int truesize); struct sk_buff *atm_alloc_charge(struct atm_vcc *vcc,int pdu_size, ===== net/atm/common.c 1.54 vs edited ===== --- 1.54/net/atm/common.c Tue Sep 23 13:38:28 2003 +++ edited/net/atm/common.c Mon Sep 29 22:24:27 2003 @@ -426,7 +426,7 @@ vcc->qos.rxtp.traffic_class == ATM_ANYCLASS) return -EINVAL; if (itf != ATM_ITF_ANY) { - dev = atm_dev_lookup(itf); + dev = atm_dev_get_by_index(itf); if (!dev) return -ENODEV; error = __vcc_connect(vcc, dev, vpi, vci); @@ -435,21 +435,19 @@ return error; } } else { - struct list_head *p, *next; + struct list_head *p; dev = NULL; - spin_lock(&atm_dev_lock); - list_for_each_safe(p, next, &atm_devs) { + rtnl_lock(); + list_for_each(p, &atm_devs) { dev = list_entry(p, struct atm_dev, dev_list); atm_dev_hold(dev); - spin_unlock(&atm_dev_lock); if (!__vcc_connect(vcc, dev, vpi, vci)) break; - atm_dev_put(dev); + __atm_dev_put(dev); dev = NULL; - spin_lock(&atm_dev_lock); } - spin_unlock(&atm_dev_lock); + rtnl_unlock(); if (!dev) return -ENODEV; } ===== net/atm/resources.c 1.21 vs edited ===== --- 1.21/net/atm/resources.c Thu Sep 11 06:41:52 2003 +++ edited/net/atm/resources.c Tue Sep 30 07:10:43 2003 @@ -24,7 +24,7 @@ LIST_HEAD(atm_devs); -spinlock_t atm_dev_lock = SPIN_LOCK_UNLOCKED; +static rwlock_t atm_dev_lock = RW_LOCK_UNLOCKED; static struct atm_dev *__alloc_atm_dev(const char *type) { @@ -47,7 +47,7 @@ kfree(dev); } -static struct atm_dev *__atm_dev_lookup(int number) +static struct atm_dev *__atm_dev_get_by_index(int number) { struct atm_dev *dev; struct list_head *p; @@ -55,27 +55,65 @@ list_for_each(p, &atm_devs) { dev = list_entry(p, struct atm_dev, dev_list); if ((dev->ops) && (dev->number == number)) { - atm_dev_hold(dev); return dev; } } return NULL; } -struct atm_dev *atm_dev_lookup(int number) +struct atm_dev *atm_dev_get_by_index(int number) { struct atm_dev *dev; - spin_lock(&atm_dev_lock); - dev = __atm_dev_lookup(number); - spin_unlock(&atm_dev_lock); + read_lock(&atm_dev_lock); + dev = __atm_dev_get_by_index(number); + if (dev) + atm_dev_hold(dev); + read_unlock(&atm_dev_lock); return dev; } +static int register_atmdevice(struct atm_dev *dev) +{ + write_lock_irq(&atm_dev_lock); + list_add_tail(&dev->dev_list, &atm_devs); + atm_dev_hold(dev); + write_unlock_irq(&atm_dev_lock); + + if (atm_proc_dev_register(dev) < 0) { + printk(KERN_ERR "atm_dev_register: " + "atm_proc_dev_register failed for dev %s\n", + dev->type); + write_lock_irq(&atm_dev_lock); + list_del(&dev->dev_list); + write_unlock_irq(&atm_dev_lock); + return -EIO; + } + + return 0; +} + +static int atm_dev_alloc_index(struct atm_dev *dev, int number) +{ + if (number != -1) { + if ((__atm_dev_get_by_index(number))) + return -EBUSY; + } else { + number = 0; + while ((__atm_dev_get_by_index(number))) { + number++; + } + } + dev->number = number; + + return 0; +} + struct atm_dev *atm_dev_register(const char *type, const struct atmdev_ops *ops, int number, unsigned long *flags) { - struct atm_dev *dev, *inuse; + struct atm_dev *dev; + int err; dev = __alloc_atm_dev(type); if (!dev) { @@ -83,60 +121,51 @@ type); return NULL; } - spin_lock(&atm_dev_lock); - if (number != -1) { - if ((inuse = __atm_dev_lookup(number))) { - atm_dev_put(inuse); - spin_unlock(&atm_dev_lock); - __free_atm_dev(dev); - return NULL; - } - dev->number = number; - } else { - dev->number = 0; - while ((inuse = __atm_dev_lookup(dev->number))) { - atm_dev_put(inuse); - dev->number++; - } - } dev->ops = ops; if (flags) dev->flags = *flags; - else - memset(&dev->flags, 0, sizeof(dev->flags)); - memset(&dev->stats, 0, sizeof(dev->stats)); - atomic_set(&dev->refcnt, 1); - list_add_tail(&dev->dev_list, &atm_devs); - spin_unlock(&atm_dev_lock); - if (atm_proc_dev_register(dev) < 0) { - printk(KERN_ERR "atm_dev_register: " - "atm_proc_dev_register failed for dev %s\n", - type); - spin_lock(&atm_dev_lock); - list_del(&dev->dev_list); - spin_unlock(&atm_dev_lock); + rtnl_lock(); + + err = atm_dev_alloc_index(dev, number); + if (err < 0) + goto out; + + err = register_atmdevice(dev); + +out: + rtnl_unlock(); + + if (err < 0) { __free_atm_dev(dev); - return NULL; + dev = NULL; } - + return dev; } +static void unregister_atmdevice(struct atm_dev *dev) +{ + atm_proc_dev_deregister(dev); + + write_lock_irq(&atm_dev_lock); + list_del(&dev->dev_list); + write_unlock_irq(&atm_dev_lock); + + atm_dev_put(dev); +} void atm_dev_deregister(struct atm_dev *dev) { unsigned long warning_time; - atm_proc_dev_deregister(dev); - - spin_lock(&atm_dev_lock); - list_del(&dev->dev_list); - spin_unlock(&atm_dev_lock); + rtnl_lock(); + unregister_atmdevice(dev); + rtnl_unlock(); warning_time = jiffies; - while (atomic_read(&dev->refcnt) != 1) { + while (atomic_read(&dev->refcnt) != 0) { current->state = TASK_INTERRUPTIBLE; schedule_timeout(HZ / 4); current->state = TASK_RUNNING; @@ -153,7 +182,7 @@ void shutdown_atm_dev(struct atm_dev *dev) { - if (atomic_read(&dev->refcnt) > 1) { + if (atomic_read(&dev->refcnt) > 0) { set_bit(ATM_DF_CLOSE, &dev->flags); return; } @@ -217,23 +246,23 @@ return -EFAULT; if (get_user(len, &((struct atm_iobuf *) arg)->length)) return -EFAULT; - spin_lock(&atm_dev_lock); + read_lock(&atm_dev_lock); list_for_each(p, &atm_devs) size += sizeof(int); if (size > len) { - spin_unlock(&atm_dev_lock); + read_unlock(&atm_dev_lock); return -E2BIG; } tmp_buf = tmp_bufp = kmalloc(size, GFP_ATOMIC); if (!tmp_buf) { - spin_unlock(&atm_dev_lock); + read_unlock(&atm_dev_lock); return -ENOMEM; } list_for_each(p, &atm_devs) { dev = list_entry(p, struct atm_dev, dev_list); *tmp_bufp++ = dev->number; } - spin_unlock(&atm_dev_lock); + read_unlock(&atm_dev_lock); error = (copy_to_user(buf, tmp_buf, size) || put_user(size, &((struct atm_iobuf *) arg)->length)) ? -EFAULT : 0; @@ -248,7 +277,7 @@ if (get_user(number, &((struct atmif_sioc *) arg)->number)) return -EFAULT; - if (!(dev = atm_dev_lookup(number))) + if (!(dev = atm_dev_get_by_index(number))) return -ENODEV; switch (cmd) { @@ -411,13 +440,13 @@ void *atm_dev_seq_start(struct seq_file *seq, loff_t *pos) { - spin_lock(&atm_dev_lock); + read_lock(&atm_dev_lock); return *pos ? dev_get_idx(*pos) : (void *) 1; } void atm_dev_seq_stop(struct seq_file *seq, void *v) { - spin_unlock(&atm_dev_lock); + read_unlock(&atm_dev_lock); } void *atm_dev_seq_next(struct seq_file *seq, void *v, loff_t *pos) @@ -430,5 +459,5 @@ EXPORT_SYMBOL(atm_dev_register); EXPORT_SYMBOL(atm_dev_deregister); -EXPORT_SYMBOL(atm_dev_lookup); +EXPORT_SYMBOL(atm_dev_get_by_index); EXPORT_SYMBOL(shutdown_atm_dev); ===== net/atm/resources.h 1.13 vs edited ===== --- 1.13/net/atm/resources.h Mon Sep 8 13:27:12 2003 +++ edited/net/atm/resources.h Mon Sep 29 22:03:48 2003 @@ -11,7 +11,6 @@ extern struct list_head atm_devs; -extern spinlock_t atm_dev_lock; int atm_dev_ioctl(unsigned int cmd, unsigned long arg); From davem@pizda.ninka.net Wed Oct 1 05:46:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 05:47:01 -0700 (PDT) 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 h91CkRFx031412 for ; Wed, 1 Oct 2003 05:46:27 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id FAA07095; Wed, 1 Oct 2003 05:42:26 -0700 Date: Wed, 1 Oct 2003 05:42:26 -0700 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com Subject: Re: [RFC] add rtnl semaphore to linux-atm Message-Id: <20031001054226.126cea7b.davem@redhat.com> In-Reply-To: <200310011134.h91BYPkT003172@ginger.cmf.nrl.navy.mil> References: <200310011134.h91BYPkT003172@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.2 (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: 431 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 Content-Length: 596 Lines: 15 On Wed, 01 Oct 2003 07:34:25 -0400 chas williams wrote: > i am thinking about doing the following to fix the race > during ATM_ITF_ANY operation. rtnl is held across > registration/unregistration. this means that you can get > read-only access to the device list by holding rtnl > or a read_lock on atm_dev_lock similar to the scheme > used by netdevice (or so i think). This looks like it would work. Although, unless VCC connect can potentially sleep, it might be better to keep exporting the rwlock and take it as a reader instead of grabbing the rtnl semaphore. From chas@cmf.nrl.navy.mil Wed Oct 1 06:07:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 06:08:26 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91D7nFx031941 for ; Wed, 1 Oct 2003 06:07:50 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id h91D7jkT004153; Wed, 1 Oct 2003 09:07:45 -0400 (EDT) Message-Id: <200310011307.h91D7jkT004153@ginger.cmf.nrl.navy.mil> To: "David S. Miller" cc: netdev@oss.sgi.com Subject: Re: [RFC] add rtnl semaphore to linux-atm In-Reply-To: Message from "David S. Miller" of "Wed, 01 Oct 2003 05:42:26 PDT." <20031001054226.126cea7b.davem@redhat.com> Date: Wed, 01 Oct 2003 09:07:45 -0400 From: chas williams X-Spam-Score: () hits=-0.9 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 432 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 409 Lines: 8 In message <20031001054226.126cea7b.davem@redhat.com>,"David S. Miller" writes: >Although, unless VCC connect can potentially sleep, it might >be better to keep exporting the rwlock and take it as a reader >instead of grabbing the rtnl semaphore. i had initially written it that way but remembered at one point i was going to use the rtnl semaphore to handle this problem. any opinions on what is 'better'? From davem@pizda.ninka.net Wed Oct 1 06:18:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 06:19:05 -0700 (PDT) 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 h91DIVFx032309 for ; Wed, 1 Oct 2003 06:18:31 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id GAA07219; Wed, 1 Oct 2003 06:14:26 -0700 Date: Wed, 1 Oct 2003 06:14:26 -0700 From: "David S. Miller" To: chas williams Cc: netdev@oss.sgi.com Subject: Re: [RFC] add rtnl semaphore to linux-atm Message-Id: <20031001061426.0b67a235.davem@redhat.com> In-Reply-To: <200310011307.h91D7jkT004153@ginger.cmf.nrl.navy.mil> References: <20031001054226.126cea7b.davem@redhat.com> <200310011307.h91D7jkT004153@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.2 (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: 433 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 Content-Length: 779 Lines: 18 On Wed, 01 Oct 2003 09:07:45 -0400 chas williams wrote: > i had initially written it that way but remembered at one point i > was going to use the rtnl semaphore to handle this problem. any > opinions on what is 'better'? Blocking all network configuration operations (even ones not for your subsystem) is a little bit anti-social in SMP cases. If you take the rwlock as a reader, you only interfere with a very minute class of network configuration code paths (those that need to take the rwlock in question as a writer). For example, if you use the rwlock-as-reader approach, someone doing IPV4 routing table updates (ie. routing daemon changing a couple thousand routes after a BGP flap) won't be perturbed while the ATM operation is in progress. From vinay.nallamothu@gsecone.com Wed Oct 1 07:07:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 07:08:20 -0700 (PDT) Received: from gateway.gsecone.com ([61.95.227.64]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91E7eFx004290 for ; Wed, 1 Oct 2003 07:07:41 -0700 Received: from vinay.gsecone.com (vinay.gsecone.com [192.168.1.15]) by gateway.gsecone.com (8.12.8/8.12.8) with ESMTP id h91EAJBU010227; Wed, 1 Oct 2003 19:40:19 +0530 Subject: [PATCH 2.6.0-test6][ROSE] timer cleanups (and couple of fixes) From: Vinay K Nallamothu To: netdev@oss.sgi.com Cc: LKML Content-Type: text/plain Organization: Global Security One Message-Id: <1065017300.7194.318.camel@lima.royalchallenge.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 01 Oct 2003 19:38:20 +0530 Content-Transfer-Encoding: 7bit X-archive-position: 434 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vinay.nallamothu@gsecone.com Precedence: bulk X-list: netdev Content-Length: 9219 Lines: 318 1. Use mod_timer 2. Use del_timer_sync in rose_loopback_clear 3. Use static timer initializer 4. set skb->destructor = NULL wherever skb->sk = NULL before kfree_skb(skb) I am not clear why skb->sk is set to NULL in the exit path in rose_loopback_clear. Isn't it sufficient to purge the entire queue? Let me know if this is the right fix. af_rose.c | 10 +++------ rose_link.c | 21 +++++++++--------- rose_loopback.c | 30 +++++++-------------------- rose_route.c | 7 ++---- rose_timer.c | 62 ++++++++++++++++++-------------------------------------- 5 files changed, 46 insertions(+), 84 deletions(-) diff -urN -X dontdiff linux-2.6.0-test6/net/rose/af_rose.c linux-2.6.0-test6-nvk/net/rose/af_rose.c --- linux-2.6.0-test6/net/rose/af_rose.c 2003-10-01 14:03:23.000000000 +0530 +++ linux-2.6.0-test6-nvk/net/rose/af_rose.c 2003-10-01 18:49:28.000000000 +0530 @@ -64,6 +64,7 @@ ax25_address rose_callsign; +void rose_init_timers(struct sock *sk); /* * Convert a ROSE address into text. */ @@ -353,10 +354,8 @@ if (atomic_read(&sk->sk_wmem_alloc) || atomic_read(&sk->sk_rmem_alloc)) { /* Defer: outstanding buffers */ - init_timer(&sk->sk_timer); sk->sk_timer.expires = jiffies + 10 * HZ; sk->sk_timer.function = rose_destroy_timer; - sk->sk_timer.data = (unsigned long)sk; add_timer(&sk->sk_timer); } else sk_free(sk); @@ -529,8 +528,7 @@ sock->ops = &rose_proto_ops; sk->sk_protocol = protocol; - init_timer(&rose->timer); - init_timer(&rose->idletimer); + rose_init_timers(sk); rose->t1 = sysctl_rose_call_request_timeout; rose->t2 = sysctl_rose_reset_request_timeout; @@ -576,8 +574,7 @@ sk->sk_sleep = osk->sk_sleep; sk->sk_zapped = osk->sk_zapped; - init_timer(&rose->timer); - init_timer(&rose->idletimer); + rose_init_timers(sk); orose = rose_sk(osk); rose->t1 = orose->t1; @@ -883,6 +880,7 @@ /* Now attach up the new socket */ skb->sk = NULL; + skb->destructor = NULL; kfree_skb(skb); sk->sk_ack_backlog--; newsock->sk = newsk; diff -urN -X dontdiff linux-2.6.0-test6/net/rose/rose_link.c linux-2.6.0-test6-nvk/net/rose/rose_link.c --- linux-2.6.0-test6/net/rose/rose_link.c 2003-09-09 11:12:05.000000000 +0530 +++ linux-2.6.0-test6-nvk/net/rose/rose_link.c 2003-10-01 17:41:54.000000000 +0530 @@ -31,26 +31,25 @@ static void rose_ftimer_expiry(unsigned long); static void rose_t0timer_expiry(unsigned long); -void rose_start_ftimer(struct rose_neigh *neigh) +void rose_neigh_init_timers(struct rose_neigh *neigh) { - del_timer(&neigh->ftimer); + init_timer(&neigh->t0timer); + neigh->t0timer.data = (unsigned long)neigh; + neigh->t0timer.function = &rose_t0timer_expiry; + init_timer(&neigh->ftimer); neigh->ftimer.data = (unsigned long)neigh; neigh->ftimer.function = &rose_ftimer_expiry; - neigh->ftimer.expires = jiffies + sysctl_rose_link_fail_timeout; +} - add_timer(&neigh->ftimer); +void rose_start_ftimer(struct rose_neigh *neigh) +{ + mod_timer(&neigh->ftimer, jiffies + sysctl_rose_link_fail_timeout); } void rose_start_t0timer(struct rose_neigh *neigh) { - del_timer(&neigh->t0timer); - - neigh->t0timer.data = (unsigned long)neigh; - neigh->t0timer.function = &rose_t0timer_expiry; - neigh->t0timer.expires = jiffies + sysctl_rose_restart_request_timeout; - - add_timer(&neigh->t0timer); + mod_timer(&neigh->t0timer, jiffies + sysctl_rose_restart_request_timeout); } void rose_stop_ftimer(struct rose_neigh *neigh) diff -urN -X dontdiff linux-2.6.0-test6/net/rose/rose_loopback.c linux-2.6.0-test6-nvk/net/rose/rose_loopback.c --- linux-2.6.0-test6/net/rose/rose_loopback.c 2003-09-09 11:12:05.000000000 +0530 +++ linux-2.6.0-test6-nvk/net/rose/rose_loopback.c 2003-10-01 19:29:42.000000000 +0530 @@ -14,19 +14,17 @@ #include #include -static struct sk_buff_head loopback_queue; -static struct timer_list loopback_timer; +static void rose_loopback_timer(unsigned long); -static void rose_set_loopback_timer(void); +static struct sk_buff_head loopback_queue; +static struct timer_list loopback_timer = TIMER_INITIALIZER(rose_loopback_timer, 0, 0); -void rose_loopback_init(void) +void __init rose_loopback_init(void) { skb_queue_head_init(&loopback_queue); - - init_timer(&loopback_timer); } -static int rose_loopback_running(void) +static inline int rose_loopback_running(void) { return timer_pending(&loopback_timer); } @@ -43,25 +41,12 @@ skb_queue_tail(&loopback_queue, skbn); if (!rose_loopback_running()) - rose_set_loopback_timer(); + mod_timer(&loopback_timer, jiffies + 10); } return 1; } -static void rose_loopback_timer(unsigned long); - -static void rose_set_loopback_timer(void) -{ - del_timer(&loopback_timer); - - loopback_timer.data = 0; - loopback_timer.function = &rose_loopback_timer; - loopback_timer.expires = jiffies + 10; - - add_timer(&loopback_timer); -} - static void rose_loopback_timer(unsigned long param) { struct sk_buff *skb; @@ -102,10 +87,11 @@ { struct sk_buff *skb; - del_timer(&loopback_timer); + del_timer_sync(&loopback_timer); while ((skb = skb_dequeue(&loopback_queue)) != NULL) { skb->sk = NULL; + skb->destructor = NULL; kfree_skb(skb); } } diff -urN -X dontdiff linux-2.6.0-test6/net/rose/rose_route.c linux-2.6.0-test6-nvk/net/rose/rose_route.c --- linux-2.6.0-test6/net/rose/rose_route.c 2003-10-01 14:03:23.000000000 +0530 +++ linux-2.6.0-test6-nvk/net/rose/rose_route.c 2003-10-01 17:41:54.000000000 +0530 @@ -49,6 +49,7 @@ struct rose_neigh *rose_loopback_neigh; static void rose_remove_neigh(struct rose_neigh *); +void rose_neigh_init_timers(struct rose_neigh *); /* * Add a new route to a node, and in the process add the node and the @@ -106,8 +107,7 @@ skb_queue_head_init(&rose_neigh->queue); - init_timer(&rose_neigh->ftimer); - init_timer(&rose_neigh->t0timer); + rose_neigh_init_timers(rose_neigh); if (rose_route->ndigis != 0) { if ((rose_neigh->digipeat = kmalloc(sizeof(ax25_digi), GFP_KERNEL)) == NULL) { @@ -389,8 +389,7 @@ skb_queue_head_init(&rose_loopback_neigh->queue); - init_timer(&rose_loopback_neigh->ftimer); - init_timer(&rose_loopback_neigh->t0timer); + rose_neigh_init_timers(rose_loopback_neigh); spin_lock_bh(&rose_neigh_list_lock); rose_loopback_neigh->next = rose_neigh_list; diff -urN -X dontdiff linux-2.6.0-test6/net/rose/rose_timer.c linux-2.6.0-test6-nvk/net/rose/rose_timer.c --- linux-2.6.0-test6/net/rose/rose_timer.c 2003-09-09 11:12:05.000000000 +0530 +++ linux-2.6.0-test6-nvk/net/rose/rose_timer.c 2003-10-01 17:41:54.000000000 +0530 @@ -33,82 +33,62 @@ static void rose_timer_expiry(unsigned long); static void rose_idletimer_expiry(unsigned long); -void rose_start_heartbeat(struct sock *sk) +void rose_init_timers(struct sock *sk) { - del_timer(&sk->sk_timer); + rose_cb *rose = rose_sk(sk); + + init_timer(&rose->timer); + rose->timer.data = (unsigned long)sk; + rose->timer.function = &rose_timer_expiry; + init_timer(&rose->idletimer); + rose->idletimer.data = (unsigned long)sk; + rose->idletimer.function = &rose_idletimer_expiry; + + /* initialized by sock_init_data */ sk->sk_timer.data = (unsigned long)sk; sk->sk_timer.function = &rose_heartbeat_expiry; - sk->sk_timer.expires = jiffies + 5 * HZ; +} - add_timer(&sk->sk_timer); +void rose_start_heartbeat(struct sock *sk) +{ + mod_timer(&sk->sk_timer, jiffies + 5 * HZ); } void rose_start_t1timer(struct sock *sk) { rose_cb *rose = rose_sk(sk); - del_timer(&rose->timer); - - rose->timer.data = (unsigned long)sk; - rose->timer.function = &rose_timer_expiry; - rose->timer.expires = jiffies + rose->t1; - - add_timer(&rose->timer); + mod_timer(&rose->timer, jiffies + rose->t1); } void rose_start_t2timer(struct sock *sk) { rose_cb *rose = rose_sk(sk); - del_timer(&rose->timer); - - rose->timer.data = (unsigned long)sk; - rose->timer.function = &rose_timer_expiry; - rose->timer.expires = jiffies + rose->t2; - - add_timer(&rose->timer); + mod_timer(&rose->timer, jiffies + rose->t2); } void rose_start_t3timer(struct sock *sk) { rose_cb *rose = rose_sk(sk); - del_timer(&rose->timer); - - rose->timer.data = (unsigned long)sk; - rose->timer.function = &rose_timer_expiry; - rose->timer.expires = jiffies + rose->t3; - - add_timer(&rose->timer); + mod_timer(&rose->timer, jiffies + rose->t3); } void rose_start_hbtimer(struct sock *sk) { rose_cb *rose = rose_sk(sk); - del_timer(&rose->timer); - - rose->timer.data = (unsigned long)sk; - rose->timer.function = &rose_timer_expiry; - rose->timer.expires = jiffies + rose->hb; - - add_timer(&rose->timer); + mod_timer(&rose->timer, jiffies + rose->hb); } void rose_start_idletimer(struct sock *sk) { rose_cb *rose = rose_sk(sk); - del_timer(&rose->idletimer); - - if (rose->idle > 0) { - rose->idletimer.data = (unsigned long)sk; - rose->idletimer.function = &rose_idletimer_expiry; - rose->idletimer.expires = jiffies + rose->idle; - - add_timer(&rose->idletimer); - } + if (rose->idle > 0) + mod_timer(&rose->idletimer, jiffies + rose->idle); } void rose_stop_heartbeat(struct sock *sk) From vinay.nallamothu@gsecone.com Wed Oct 1 07:26:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 07:26:43 -0700 (PDT) Received: from gateway.gsecone.com ([61.95.227.64]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91EPoFx005789 for ; Wed, 1 Oct 2003 07:26:02 -0700 Received: from vinay.gsecone.com (vinay.gsecone.com [192.168.1.15]) by gateway.gsecone.com (8.12.8/8.12.8) with ESMTP id h91ESQBU010427; Wed, 1 Oct 2003 19:58:26 +0530 Subject: [PATCH 2.6.0-test6][X25] timer cleanup From: Vinay K Nallamothu To: netdev@oss.sgi.com Cc: LKML Content-Type: text/plain Organization: Global Security One Message-Id: <1065018387.7194.336.camel@lima.royalchallenge.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 01 Oct 2003 19:56:27 +0530 Content-Transfer-Encoding: 7bit X-archive-position: 435 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vinay.nallamothu@gsecone.com Precedence: bulk X-list: netdev Content-Length: 4995 Lines: 182 Replace del_timer, mod_timer sequences with mod_timer. af_x25.c | 8 ++++---- x25_link.c | 16 ++++++---------- x25_timer.c | 47 +++++++++++++++-------------------------------- 3 files changed, 25 insertions(+), 46 deletions(-) diff -urN linux-2.6.0-test5/net/x25/af_x25.c linux-2.6.0-test5-nvk/net/x25/af_x25.c --- linux-2.6.0-test5/net/x25/af_x25.c 2003-09-09 11:12:07.000000000 +0530 +++ linux-2.6.0-test5-nvk/net/x25/af_x25.c 2003-09-22 17:20:20.000000000 +0530 @@ -345,10 +345,8 @@ if (atomic_read(&sk->sk_wmem_alloc) || atomic_read(&sk->sk_rmem_alloc)) { /* Defer: outstanding buffers */ - init_timer(&sk->sk_timer); sk->sk_timer.expires = jiffies + 10 * HZ; sk->sk_timer.function = x25_destroy_timer; - sk->sk_timer.data = (unsigned long)sk; add_timer(&sk->sk_timer); } else { /* drop last reference so sock_put will free */ @@ -463,6 +461,8 @@ goto out; } +void x25_init_timers(struct sock *sk); + static int x25_create(struct socket *sock, int protocol) { struct sock *sk; @@ -481,7 +481,7 @@ sock_init_data(sock, sk); sk_set_owner(sk, THIS_MODULE); - init_timer(&x25->timer); + x25_init_timers(sk); sock->ops = &x25_proto_ops; sk->sk_protocol = protocol; @@ -537,7 +537,7 @@ x25->facilities = ox25->facilities; x25->qbitincl = ox25->qbitincl; - init_timer(&x25->timer); + x25_init_timers(sk); out: return sk; } diff -urN linux-2.6.0-test5/net/x25/x25_link.c linux-2.6.0-test5-nvk/net/x25/x25_link.c --- linux-2.6.0-test5/net/x25/x25_link.c 2003-09-09 11:12:07.000000000 +0530 +++ linux-2.6.0-test5-nvk/net/x25/x25_link.c 2003-09-22 19:32:14.000000000 +0530 @@ -51,15 +51,9 @@ /* * Linux set/reset timer routines */ -static void x25_start_t20timer(struct x25_neigh *nb) +static inline void x25_start_t20timer(struct x25_neigh *nb) { - del_timer(&nb->t20timer); - - nb->t20timer.data = (unsigned long)nb; - nb->t20timer.function = &x25_t20timer_expiry; - nb->t20timer.expires = jiffies + nb->t20; - - add_timer(&nb->t20timer); + mod_timer(&nb->t20timer, jiffies + nb->t20); } static void x25_t20timer_expiry(unsigned long param) @@ -71,12 +65,12 @@ x25_start_t20timer(nb); } -static void x25_stop_t20timer(struct x25_neigh *nb) +static inline void x25_stop_t20timer(struct x25_neigh *nb) { del_timer(&nb->t20timer); } -static int x25_t20timer_pending(struct x25_neigh *nb) +static inline int x25_t20timer_pending(struct x25_neigh *nb) { return timer_pending(&nb->t20timer); } @@ -291,6 +285,8 @@ skb_queue_head_init(&nb->queue); init_timer(&nb->t20timer); + nb->t20timer.data = (unsigned long)nb; + nb->t20timer.function = &x25_t20timer_expiry; dev_hold(dev); nb->dev = dev; diff -urN linux-2.6.0-test5/net/x25/x25_timer.c linux-2.6.0-test5-nvk/net/x25/x25_timer.c --- linux-2.6.0-test5/net/x25/x25_timer.c 2003-09-09 11:12:07.000000000 +0530 +++ linux-2.6.0-test5-nvk/net/x25/x25_timer.c 2003-09-22 17:23:46.000000000 +0530 @@ -43,15 +43,22 @@ static void x25_heartbeat_expiry(unsigned long); static void x25_timer_expiry(unsigned long); -void x25_start_heartbeat(struct sock *sk) +void x25_init_timers(struct sock *sk) { - del_timer(&sk->sk_timer); + struct x25_opt *x25 = x25_sk(sk); + init_timer(&x25->timer); + x25->timer.data = (unsigned long)sk; + x25->timer.function = &x25_timer_expiry; + + /* initialized by sock_init_data */ sk->sk_timer.data = (unsigned long)sk; sk->sk_timer.function = &x25_heartbeat_expiry; - sk->sk_timer.expires = jiffies + 5 * HZ; +} - add_timer(&sk->sk_timer); +void x25_start_heartbeat(struct sock *sk) +{ + mod_timer(&sk->sk_timer, jiffies + 5 * HZ); } void x25_stop_heartbeat(struct sock *sk) @@ -63,52 +70,28 @@ { struct x25_opt *x25 = x25_sk(sk); - del_timer(&x25->timer); - - x25->timer.data = (unsigned long)sk; - x25->timer.function = &x25_timer_expiry; - x25->timer.expires = jiffies + x25->t2; - - add_timer(&x25->timer); + mod_timer(&x25->timer, jiffies + x25->t2); } void x25_start_t21timer(struct sock *sk) { struct x25_opt *x25 = x25_sk(sk); - del_timer(&x25->timer); - - x25->timer.data = (unsigned long)sk; - x25->timer.function = &x25_timer_expiry; - x25->timer.expires = jiffies + x25->t21; - - add_timer(&x25->timer); + mod_timer(&x25->timer, jiffies + x25->t21); } void x25_start_t22timer(struct sock *sk) { struct x25_opt *x25 = x25_sk(sk); - del_timer(&x25->timer); - - x25->timer.data = (unsigned long)sk; - x25->timer.function = &x25_timer_expiry; - x25->timer.expires = jiffies + x25->t22; - - add_timer(&x25->timer); + mod_timer(&x25->timer, jiffies + x25->t22); } void x25_start_t23timer(struct sock *sk) { struct x25_opt *x25 = x25_sk(sk); - del_timer(&x25->timer); - - x25->timer.data = (unsigned long)sk; - x25->timer.function = &x25_timer_expiry; - x25->timer.expires = jiffies + x25->t23; - - add_timer(&x25->timer); + mod_timer(&x25->timer, jiffies + x25->t23); } void x25_stop_timer(struct sock *sk) From rddunlap@osdl.org Wed Oct 1 07:49:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 07:49:37 -0700 (PDT) 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 h91EmxFx007998 for ; Wed, 1 Oct 2003 07:49:00 -0700 Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h91Emh121348; Wed, 1 Oct 2003 07:48:43 -0700 Date: Wed, 1 Oct 2003 07:40:36 -0700 From: "Randy.Dunlap" To: "Feldman, Scott" Cc: davem@redhat.com, jgarzik@pobox.com, akpm@osdl.org, netdev@oss.sgi.com, cramerj@intel.com Subject: Re: Fw: Badness in local_bh_enable at kernel/softirq.c:119 Message-Id: <20031001074036.466ded68.rddunlap@osdl.org> In-Reply-To: References: Organization: OSDL X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: +5V?h'hZQPB9kW Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 436 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 Content-Length: 1286 Lines: 36 On Wed, 1 Oct 2003 01:19:41 -0700 "Feldman, Scott" wrote: | Chris can jump in here anytime. :-) | | Synchronizing on the hardware side is stumping me. We have the list of | skbs you describe, but I'm concerned about unmapping the skb buffers if | hardware is right in the middle of some DMA on one of the buffers. | Some archs really don't like hardware accessing unmapped buffers. | | Here's what I'm thinking: when link down is detected in the timer, just | trick hardware into thinking link is still up (ILOS - Invert Loss of | Signal). No locking, no disabling of interrupts. Hardware will do the | natural thing by completing the outstanding sends and also provide the | interrupts so we can clean/return skbs as normal (e1000_clean_tx_irq). | Something like: | | | if lost link | if outstanding Tx work | set ILOS // h/w thinks link is | up, DMA continues | mdelay(10) | clear ILOS // h/w thinks link is | down | | The mdelay(10) is terrible, but we've already got that in the current | tx_flush routine. | | Chris, what am I missing? I didn't included the ANE business for | clarity. What happens if the link comes back up (live) during the mdelay period? Tiny race? Just a delay until it's corrected? -- ~Randy From ctindel@calma.pair.com Wed Oct 1 11:26:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 11:26:51 -0700 (PDT) Received: from calma.pair.com (calma.pair.com [209.68.1.95]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91IQAFx002935 for ; Wed, 1 Oct 2003 11:26:11 -0700 Received: (qmail 25601 invoked by uid 3059); 1 Oct 2003 18:26:10 -0000 Date: Wed, 1 Oct 2003 14:26:10 -0400 From: "Chad N. Tindel" To: Shmulik Hen Cc: "David S. Miller" , "Chad N. Tindel" , fubar@us.ibm.com, jgarzik@pobox.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] Re: [bonding] compatibilty issues Message-ID: <20031001182610.GA25218@calma.pair.com> Mail-Followup-To: Shmulik Hen , "David S. Miller" , "Chad N. Tindel" , fubar@us.ibm.com, jgarzik@pobox.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com References: <200310011149.04612.shmulik.hen@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310011149.04612.shmulik.hen@intel.com> User-Agent: Mutt/1.4i X-archive-position: 437 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chad@tindel.net Precedence: bulk X-list: netdev Content-Length: 659 Lines: 15 > So here is what I did in the meantime: > * Created a version for 2.4 that puts back all old compatibility stuff > that was removed either during the propagation set or the cleanup > set. > * Created a version for 2.6 that puts back just the compatibility > stuff that was removed in the propagation set (BOND_SETHWADDR, since > we got a complaint from a RH9 user). > * Removed the mention of the multicast param from the read-me. > * Raised the ABI version to 2 so the new ifenslave keeps propagating > IP settings to slaves for older drivers, and doesn't do that for new > ones that contain Willy Tarreau's panic fix. I like this. Chad From bwindle@fint.org Wed Oct 1 11:41:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 11:41:47 -0700 (PDT) Received: from mta01-srv.alltel.net (mta01.alltel.net [166.102.165.143]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91IfDFx004256 for ; Wed, 1 Oct 2003 11:41:14 -0700 Received: from morpheus ([151.213.164.243]) by mta01-srv.alltel.net with ESMTP id <20031001184113.DJKQ25097.mta01-srv.alltel.net@morpheus> for ; Wed, 1 Oct 2003 13:41:13 -0500 Received: from bwindle (helo=localhost) by morpheus with local-esmtp (Exim 3.36 #1 (Debian)) id 1A4luP-0000eA-00 for ; Wed, 01 Oct 2003 14:41:09 -0400 Date: Wed, 1 Oct 2003 14:41:09 -0400 (EDT) From: Burton Windle X-X-Sender: bwindle@morpheus To: netdev@oss.sgi.com Subject: [RFC] Silencing needless printk in socket.c Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 438 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bwindle@fint.org Precedence: bulk X-list: netdev Content-Length: 592 Lines: 18 Would anyone object to a patch that wraps the printk in linux/net/socket.c:1897 in a 'if debug'? This first appeared around 2.6.0-test5; the output may be helpful to a developer, but I don't think it is needed in the normal dmesg. dual266:/home/kernel/linux/net# dmesg | grep NET NET: Registered protocol family 16 NET: Registered protocol family 2 NET: Registered protocol family 1 NET: Registered protocol family 17 -- Burton Windle burton@fint.org Linux: the "grim reaper of innocent orphaned children." from /usr/src/linux-2.4.18/init/main.c:461 From fubar@us.ibm.com Wed Oct 1 12:26:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 12:26:49 -0700 (PDT) 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 h91JQGFx010335 for ; Wed, 1 Oct 2003 12:26:16 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id h91JPZjZ291204; Wed, 1 Oct 2003 15:25:35 -0400 Received: from death.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h91JPWuX151268; Wed, 1 Oct 2003 13:25:34 -0600 Received: from us.ibm.com (fubar@localhost) by death.ibm.com (8.12.5/8.12.5/Submit) with ESMTP id h91JPJXZ001948; Wed, 1 Oct 2003 12:25:22 -0700 Message-Id: <200310011925.h91JPJXZ001948@death.ibm.com> X-Authentication-Warning: death.ibm.com: fubar owned process doing -bs To: Shmulik Hen , "David S. Miller" , "Chad N. Tindel" , jgarzik@pobox.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] Re: [bonding] compatibilty issues In-Reply-To: Message from "Chad N. Tindel" of "Wed, 01 Oct 2003 14:26:10 EDT." <20031001182610.GA25218@calma.pair.com> Date: Wed, 01 Oct 2003 12:25:19 -0700 From: Jay Vosburgh X-archive-position: 439 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1249 Lines: 29 >> So here is what I did in the meantime: >> * Created a version for 2.4 that puts back all old compatibility stuff >> that was removed either during the propagation set or the cleanup >> set. >> * Created a version for 2.6 that puts back just the compatibility >> stuff that was removed in the propagation set (BOND_SETHWADDR, since >> we got a complaint from a RH9 user). >> * Removed the mention of the multicast param from the read-me. >> * Raised the ABI version to 2 so the new ifenslave keeps propagating >> IP settings to slaves for older drivers, and doesn't do that for new >> ones that contain Willy Tarreau's panic fix. > >I like this. Same here, but I'd like to have a list somewhere of what each of the ABI versions is for and how they're supposed to behave. It's starting to look like we're going to be adding these on a semi-regular basis, so we need to keep track of what each one does and why. I also don't have any major heartburn about leaving the OLD thingies in 2.4. I'd like to remove them, but part of my reason for wanting to nuke them was to keep 2.4 and 2.6 identical, but we're not doing that, so it's not as big a concern. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From g.liakhovetski@gmx.de Wed Oct 1 12:57:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 12:58:29 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91JvuFx010882 for ; Wed, 1 Oct 2003 12:57:56 -0700 Received: (qmail 13076 invoked by uid 65534); 1 Oct 2003 19:57:48 -0000 Received: from Ba1de.pppool.de (EHLO poirot.grange) (213.7.161.222) by mail.gmx.net (mp007) with SMTP; 01 Oct 2003 21:57:48 +0200 X-Authenticated: #20450766 Received: from lyakh (helo=localhost) by poirot.grange with local-esmtp (Exim 3.35 #1 (Debian)) id 1A4mwp-0001M7-00; Wed, 01 Oct 2003 21:47:43 +0200 Date: Wed, 1 Oct 2003 21:47:43 +0200 (CEST) From: Guennadi Liakhovetski Reply-To: Guennadi Liakhovetski To: David Woodhouse cc: "David S. Miller" , , , , , , Subject: Re: RFC: [2.6 patch] disallow modular IPv6 In-Reply-To: <1064903505.6154.157.camel@imladris.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 440 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: g.liakhovetski@gmx.de Precedence: bulk X-list: netdev Content-Length: 1697 Lines: 39 On Tue, 30 Sep 2003, David Woodhouse wrote: > On Mon, 2003-09-29 at 22:17 -0700, David S. Miller wrote: > > On Mon, 29 Sep 2003 10:02:55 +0100 > > David Woodhouse wrote: > > > > > The underlying point being that your static kernel should not change if > > > you change an option from 'n' to 'm'. It should only affect the kernel > > > image if you change options to/from 'y'. > > > > I totally disagree, what ipv6 is doing is perfectly fine. > > Your right. Well, maybe you are right, but I certainly liked the feature, that I could just add a module to a currently running kernel's configuration, compile and insmod it. But, if this is how it is (going to be) now - that one shouldn't rely on this, do you agree, that such attempts should be stopped by the build system? If so, I think, a script, trying to find possible problems could be of help? It wouldn't be trivial, but maybe there's already framework available, that can be taught to do this? Ideally, you would want to check: for each tristate CONFIG_ find from the respective Makefile(s) which source (*.[Sc])-files are involved with obj-$(CONFIG_x). Find depending source-files from "depends on x" in respective Kconfig recursively. If CONFIG_x appears in any other source-files - it is already a (likely) problem. Now headers. Well, if we want to check infinitely deep inclusions - it would require a fat cluster / SMP, I guess:-) So, is there a piece of software among all automatic checkers, that could be relatively easily taught to do this and would it make sense to run such a check on each -pre and -rc version? Actually, is anybody checking for recursive includes? Guennadi --- Guennadi Liakhovetski From akpm@osdl.org Wed Oct 1 15:57:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 15:57:35 -0700 (PDT) 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 h91Muf25018824 for ; Wed, 1 Oct 2003 15:57:02 -0700 Received: from akpm-1.pao.digeo.com (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h91MuW104645; Wed, 1 Oct 2003 15:56:32 -0700 Date: Wed, 1 Oct 2003 15:56:23 -0700 From: Andrew Morton To: Vinay K Nallamothu Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2.6.0-test6][X25] timer cleanup Message-Id: <20031001155623.06b89258.akpm@osdl.org> In-Reply-To: <1065018387.7194.336.camel@lima.royalchallenge.com> References: <1065018387.7194.336.camel@lima.royalchallenge.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: 441 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 Content-Length: 134 Lines: 5 Vinay K Nallamothu wrote: > > Replace del_timer, mod_timer sequences with mod_timer. was this tested? From mashirle@us.ibm.com Wed Oct 1 16:37:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 16:38:20 -0700 (PDT) Received: from linux2.suntekindustrial.com (wbar1.sjo1-4-4-004-065.sjo1.dsl-verizon.net [4.4.4.65]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91Nbe25022416 for ; Wed, 1 Oct 2003 16:37:47 -0700 Received: from ibm-mxl (bi01p1.co.us.ibm.com [32.97.110.142]) (authenticated bits=0) by linux2.suntekindustrial.com (8.12.8/8.12.8) with ESMTP id h91NlDo7002302; Wed, 1 Oct 2003 16:47:14 -0700 Content-Type: text/plain; charset="us-ascii" From: Shirley Ma Organization: IBM Linux To: davem@redhat.com, kuznet@ms2.inr.ac.ru Subject: [PATCH] Implementation for IPv6 MIB:ipv6AddressTable Date: Wed, 1 Oct 2003 16:37:26 -0700 User-Agent: KMail/1.4.3 Cc: netdev@oss.sgi.com MIME-Version: 1.0 Message-Id: <200310011637.27013.mashirle@us.ibm.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h91Nbe25022416 X-archive-position: 442 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mashirle@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 10657 Lines: 355 I've sent my explanation of IPv6 MIBs implementation a couple of weeks back. This patch implements the IPv6 MIBs ipv6AddressTable. The implementation is based on the new last call draft of IPv6 MIBs, see link blow. It's going to be a RFC. http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-04.txt The patch has been tested against Linux-2.6.0-test5-bk12. I have made sure this applies cleanly to Linux 2.6.0-test6-bk3. Below is the patch. Please give me your comments. Thanks Shirley Ma IBM Linux Technology Center ======================= diff -urN linux-2.6.0-test5/include/linux/rtnetlink.h linux-2.6.0-test5-ipv6mib4/include/linux/rtnetlink.h --- linux-2.6.0-test5/include/linux/rtnetlink.h 2003-09-25 17:17:02.000000000 -0700 +++ linux-2.6.0-test5-ipv6mib4/include/linux/rtnetlink.h 2003-10-01 11:00:03.000000000 -0700 @@ -352,8 +352,10 @@ struct ifa_cacheinfo { - __s32 ifa_prefered; - __s32 ifa_valid; + __u32 ifa_prefered; + __u32 ifa_valid; + unsigned long cstamp; /* created time */ + unsigned long tstamp; /* updated time */ }; diff -urN linux-2.6.0-test5/include/linux/time.h linux-2.6.0-test5-ipv6mib4/include/linux/time.h --- linux-2.6.0-test5/include/linux/time.h 2003-09-08 12:50:08.000000000 -0700 +++ linux-2.6.0-test5-ipv6mib4/include/linux/time.h 2003-10-01 11:40:42.000000000 -0700 @@ -55,6 +55,7 @@ * at _least_ "jiffies" - so "jiffies+1" had better still * be positive. */ +#define MAX_JIFFIES (~0) #define MAX_JIFFY_OFFSET ((~0UL >> 1)-1) /* Parameters used to convert the timespec values */ diff -urN linux-2.6.0-test5/include/net/if_inet6.h linux-2.6.0-test5-ipv6mib4/include/net/if_inet6.h --- linux-2.6.0-test5/include/net/if_inet6.h 2003-09-25 17:17:02.000000000 -0700 +++ linux-2.6.0-test5-ipv6mib4/include/net/if_inet6.h 2003-10-01 11:23:27.000000000 -0700 @@ -34,7 +34,8 @@ __u32 valid_lft; __u32 prefered_lft; - unsigned long tstamp; + unsigned long cstamp; /* created timestamp */ + unsigned long tstamp; /* updated timestamp */ atomic_t refcnt; spinlock_t lock; @@ -111,6 +112,8 @@ atomic_t mca_refcnt; spinlock_t mca_lock; unsigned char mca_crcount; + unsigned long mca_cstamp; + unsigned long mca_tstamp; }; /* Anycast stuff */ @@ -130,6 +133,8 @@ int aca_users; atomic_t aca_refcnt; spinlock_t aca_lock; + unsigned long aca_cstamp; + unsigned long aca_tstamp; }; #define IFA_HOST IPV6_ADDR_LOOPBACK diff -urN linux-2.6.0-test5/net/ipv6/addrconf.c linux-2.6.0-test5-ipv6mib4/net/ipv6/addrconf.c --- linux-2.6.0-test5/net/ipv6/addrconf.c 2003-09-25 17:17:03.000000000 -0700 +++ linux-2.6.0-test5-ipv6mib4/net/ipv6/addrconf.c 2003-10-01 11:28:41.000000000 -0700 @@ -92,6 +92,8 @@ #define ADBG(x) #endif +#define INFINITY_LIFE_TIME 0xFFFFFFFF + #ifdef CONFIG_SYSCTL static void addrconf_sysctl_register(struct inet6_dev *idev, struct ipv6_devconf *p); static void addrconf_sysctl_unregister(struct ipv6_devconf *p); @@ -505,6 +507,7 @@ ifa->scope = scope; ifa->prefix_len = pfxlen; ifa->flags = flags | IFA_F_TENTATIVE; + ifa->cstamp = ifa->tstamp = jiffies; read_lock(&addrconf_lock); if (idev->dead) { @@ -707,6 +710,7 @@ ift->ifpub = ifp; ift->valid_lft = tmp_valid_lft; ift->prefered_lft = tmp_prefered_lft; + ift->cstamp = ifp->cstamp; ift->tstamp = ifp->tstamp; spin_unlock_bh(&ift->lock); addrconf_dad_start(ift, 0); @@ -1412,6 +1416,7 @@ } update_lft = create = 1; + ifp->cstamp = jiffies; addrconf_dad_start(ifp, RTF_ADDRCONF|RTF_PREFIX_RT); } @@ -2447,14 +2452,103 @@ if (!(ifa->flags&IFA_F_PERMANENT)) { ci.ifa_prefered = ifa->prefered_lft; ci.ifa_valid = ifa->valid_lft; - if (ci.ifa_prefered != 0xFFFFFFFF) { + if (ci.ifa_prefered != INFINITY_LIFE_TIME) { long tval = (jiffies - ifa->tstamp)/HZ; ci.ifa_prefered -= tval; - if (ci.ifa_valid != 0xFFFFFFFF) + if (ci.ifa_valid != INFINITY_LIFE_TIME) ci.ifa_valid -= tval; } - RTA_PUT(skb, IFA_CACHEINFO, sizeof(ci), &ci); + } else { + ci.ifa_prefered = INFINITY_LIFE_TIME; + ci.ifa_valid = INFINITY_LIFE_TIME; } + if (ifa->cstamp < INITIAL_JIFFIES) + ci.cstamp = (ifa->cstamp + MAX_JIFFIES - INITIAL_JIFFIES) / HZ; + else + ci.cstamp = (ifa->cstamp - INITIAL_JIFFIES) / HZ; + if (ifa->tstamp < INITIAL_JIFFIES) + ci.tstamp = (ifa->tstamp + MAX_JIFFIES - INITIAL_JIFFIES) / HZ; + else + ci.tstamp = (ifa->tstamp - INITIAL_JIFFIES) / HZ; + RTA_PUT(skb, IFA_CACHEINFO, sizeof(ci), &ci); + nlh->nlmsg_len = skb->tail - b; + return skb->len; + +nlmsg_failure: +rtattr_failure: + skb_trim(skb, b - skb->data); + return -1; +} + +static int inet6_fill_ifmcaddr(struct sk_buff *skb, struct ifmcaddr6 *ifmca, + u32 pid, u32 seq, int event) +{ + struct ifaddrmsg *ifm; + struct nlmsghdr *nlh; + struct ifa_cacheinfo ci; + unsigned char *b = skb->tail; + + nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm)); + if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; + ifm = NLMSG_DATA(nlh); + ifm->ifa_family = AF_INET6; + ifm->ifa_prefixlen = 128; + ifm->ifa_flags = IFA_F_PERMANENT; + ifm->ifa_scope = RT_SCOPE_UNIVERSE; + if (ipv6_addr_scope(&ifmca->mca_addr)&IFA_SITE) + ifm->ifa_scope = RT_SCOPE_SITE; + ifm->ifa_index = ifmca->idev->dev->ifindex; + RTA_PUT(skb, IFA_ADDRESS, 16, &ifmca->mca_addr); + if (ifmca->mca_cstamp < INITIAL_JIFFIES) + ci.cstamp = (ifmca->mca_cstamp + MAX_JIFFIES - INITIAL_JIFFIES) / HZ; + else + ci.cstamp = (ifmca->mca_cstamp - INITIAL_JIFFIES) / HZ; + if (ifmca->mca_tstamp < INITIAL_JIFFIES) + ci.tstamp = (ifmca->mca_tstamp + MAX_JIFFIES - INITIAL_JIFFIES) / HZ; + else + ci.tstamp = (ifmca->mca_tstamp - INITIAL_JIFFIES) / HZ; + ci.ifa_prefered = INFINITY_LIFE_TIME; + ci.ifa_valid = INFINITY_LIFE_TIME; + RTA_PUT(skb, IFA_CACHEINFO, sizeof(ci), &ci); + nlh->nlmsg_len = skb->tail - b; + return skb->len; + +nlmsg_failure: +rtattr_failure: + skb_trim(skb, b - skb->data); + return -1; +} + +static int inet6_fill_ifacaddr(struct sk_buff *skb, struct ifacaddr6 *ifaca, + u32 pid, u32 seq, int event) +{ + struct ifaddrmsg *ifm; + struct nlmsghdr *nlh; + struct ifa_cacheinfo ci; + unsigned char *b = skb->tail; + + nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm)); + if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; + ifm = NLMSG_DATA(nlh); + ifm->ifa_family = AF_INET6; + ifm->ifa_prefixlen = 128; + ifm->ifa_flags = IFA_F_PERMANENT; + ifm->ifa_scope = RT_SCOPE_UNIVERSE; + if (ipv6_addr_scope(&ifaca->aca_addr)&IFA_SITE) + ifm->ifa_scope = RT_SCOPE_SITE; + ifm->ifa_index = ifaca->aca_idev->dev->ifindex; + RTA_PUT(skb, IFA_ADDRESS, 16, &ifaca->aca_addr); + if (ifaca->aca_cstamp < INITIAL_JIFFIES) + ci.cstamp = (ifaca->aca_cstamp + MAX_JIFFIES - INITIAL_JIFFIES) / HZ; + else + ci.cstamp = (ifaca->aca_cstamp - INITIAL_JIFFIES) / HZ; + if (ifaca->aca_tstamp < INITIAL_JIFFIES) + ci.tstamp = (ifaca->aca_tstamp + MAX_JIFFIES - INITIAL_JIFFIES) / HZ; + else + ci.tstamp = (ifaca->aca_tstamp - INITIAL_JIFFIES) / HZ; + ci.ifa_prefered = INFINITY_LIFE_TIME; + ci.ifa_valid = INFINITY_LIFE_TIME; + RTA_PUT(skb, IFA_CACHEINFO, sizeof(ci), &ci); nlh->nlmsg_len = skb->tail - b; return skb->len; @@ -2468,33 +2562,83 @@ { int idx, ip_idx; int s_idx, s_ip_idx; - struct inet6_ifaddr *ifa; - + struct net_device *dev; + struct inet6_dev *idev; + struct inet6_ifaddr *ifa; + struct ifmcaddr6 *ifmca; + struct ifacaddr6 *ifaca; + s_idx = cb->args[0]; s_ip_idx = ip_idx = cb->args[1]; - - for (idx=0; idx < IN6_ADDR_HSIZE; idx++) { + read_lock(&dev_base_lock); + + for (dev = dev_base, idx = 0; dev; dev = dev->next, idx++) { if (idx < s_idx) continue; if (idx > s_idx) s_ip_idx = 0; - read_lock_bh(&addrconf_hash_lock); - for (ifa=inet6_addr_lst[idx], ip_idx = 0; ifa; - ifa = ifa->lst_next, ip_idx++) { + if ((idev = in6_dev_get(dev)) == NULL) + continue; + read_lock_bh(&idev->lock); + /* unicast address */ + for (ifa = idev->addr_list, ip_idx = 0; ifa; + ifa = ifa->if_next, ip_idx++) { + if (ip_idx < s_ip_idx) + continue; + if (inet6_fill_ifaddr(skb, ifa, NETLINK_CB(cb->skb).pid, + cb->nlh->nlmsg_seq, RTM_NEWADDR) <= 0) { + read_unlock(&addrconf_lock); + in6_dev_put(idev); + goto done; + } + } + /* temp addr */ +#ifdef CONFIG_IPV6_PRIVACY + for (ifa = idev->tempaddr_list; ifa; + ifa = ifua->tmp_next, ip_idx++) { if (ip_idx < s_ip_idx) continue; if (inet6_fill_ifaddr(skb, ifa, NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, RTM_NEWADDR) <= 0) { - read_unlock_bh(&addrconf_hash_lock); + cb->nlh->nlmsg_seq, RTM_NEWADDR) <= 0) { + read_unlock(&addrconf_lock); + in6_dev_put(idev); + goto done; + } + } +#endif + /* multicast address */ + for (ifmca = idev->mc_list; ifmca; + ifmca = ifmca->next, ip_idx++) { + if (ip_idx < s_ip_idx) + continue; + if (inet6_fill_ifmcaddr(skb, ifmca, + NETLINK_CB(cb->skb).pid, + cb->nlh->nlmsg_seq, RTM_NEWADDR) <= 0) { + read_unlock(&addrconf_lock); + in6_dev_put(idev); + goto done; + } + } + /* anycast address */ + for (ifaca = idev->ac_list; ifaca; + ifaca = ifaca->aca_next, ip_idx++) { + if (ip_idx < s_ip_idx) + continue; + if (inet6_fill_ifacaddr(skb, ifaca, + NETLINK_CB(cb->skb).pid, + cb->nlh->nlmsg_seq, RTM_NEWADDR) <=0) { + read_unlock(&addrconf_lock); + in6_dev_put(idev); goto done; } } - read_unlock_bh(&addrconf_hash_lock); + read_unlock(&addrconf_lock); + in6_dev_put(idev); } done: + read_unlock(&dev_base_lock); cb->args[0] = idx; cb->args[1] = ip_idx; - return skb->len; } diff -urN linux-2.6.0-test5/net/ipv6/anycast.c linux-2.6.0-test5-ipv6mib4/net/ipv6/anycast.c --- linux-2.6.0-test5/net/ipv6/anycast.c 2003-09-25 17:17:03.000000000 -0700 +++ linux-2.6.0-test5-ipv6mib4/net/ipv6/anycast.c 2003-10-01 11:23:04.000000000 -0700 @@ -343,6 +343,8 @@ ipv6_addr_copy(&aca->aca_addr, addr); aca->aca_idev = idev; aca->aca_users = 1; + /* aca_tstamp should be updated later, once it's updated */ + aca->aca_cstamp = aca->aca_tstamp = jiffies; atomic_set(&aca->aca_refcnt, 2); aca->aca_lock = SPIN_LOCK_UNLOCKED; diff -urN linux-2.6.0-test5/net/ipv6/mcast.c linux-2.6.0-test5-ipv6mib4/net/ipv6/mcast.c --- linux-2.6.0-test5/net/ipv6/mcast.c 2003-09-25 17:17:03.000000000 -0700 +++ linux-2.6.0-test5-ipv6mib4/net/ipv6/mcast.c 2003-09-30 18:40:29.000000000 -0700 @@ -830,6 +830,8 @@ ipv6_addr_copy(&mc->mca_addr, addr); mc->idev = idev; mc->mca_users = 1; + /* mca_stamp should be updated later, once it's updated */ + mc->mca_cstamp = mc->mca_tstamp = jiffies; atomic_set(&mc->mca_refcnt, 2); mc->mca_lock = SPIN_LOCK_UNLOCKED; From shmulik.hen@intel.com Wed Oct 1 23:38:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Oct 2003 23:38:43 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h926c425007239 for ; Wed, 1 Oct 2003 23:38:04 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.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 h926c0qU019463 for ; Thu, 2 Oct 2003 06:38:00 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.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 h926WSg06951 for ; Thu, 2 Oct 2003 06:32:28 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003100123375217636 ; Wed, 01 Oct 2003 23:37:54 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: "Jay Vosburgh" , "David S. Miller" , "Chad N. Tindel" , , , Subject: Re: [Bonding-devel] Re: [bonding] compatibilty issues Date: Thu, 2 Oct 2003 09:37:51 +0300 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200310020937.51781.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 443 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Content-Length: 1119 Lines: 26 On Wednesday 01 October 2003 10:25 pm, Jay Vosburgh wrote: > Same here, but I'd like to have a list somewhere of what each > of the ABI versions is for and how they're supposed to behave. > It's starting to look like we're going to be adding these on a > semi-regular basis, so we need to keep track of what each one does > and why. > Where should such a list go ? Currently, 0 or none is for doing everything the old way. 1 is for not setting slaves HW addr via ifenslave and leaving them in down state so the driver gets them with their unique address, sets them according to the mode and brings them up. The driver also restores the original address upon release. This is all done for supporting the 802.3ad, TLB, ALB modes. 2 will be for ifenslave lite that doesn't propagate the bond's IP settings to the slaves. I'm guessing that 3 will be used to designate the new support for hot operations that Amir is working on. -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From vinay.nallamothu@gsecone.com Thu Oct 2 00:02:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 00:03:29 -0700 (PDT) Received: from gateway.gsecone.com ([61.95.227.64]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9272r25009029 for ; Thu, 2 Oct 2003 00:02:54 -0700 Received: from vinay.gsecone.com (vinay.gsecone.com [192.168.1.15]) by gateway.gsecone.com (8.12.8/8.12.8) with ESMTP id h9275MBU015070; Thu, 2 Oct 2003 12:35:24 +0530 Subject: Re: [PATCH 2.6.0-test6][X25] timer cleanup From: Vinay K Nallamothu To: Andrew Morton Cc: netdev@oss.sgi.com, LKML In-Reply-To: <20031001155623.06b89258.akpm@osdl.org> References: <1065018387.7194.336.camel@lima.royalchallenge.com> <20031001155623.06b89258.akpm@osdl.org> Content-Type: text/plain Organization: Global Security One Message-Id: <1065078208.4340.3.camel@lima.royalchallenge.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 02 Oct 2003 12:33:28 +0530 Content-Transfer-Encoding: 7bit X-archive-position: 444 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vinay.nallamothu@gsecone.com Precedence: bulk X-list: netdev Content-Length: 218 Lines: 8 On Thu, 2003-10-02 at 04:26, Andrew Morton wrote: > Vinay K Nallamothu wrote: > > > > Replace del_timer, mod_timer sequences with mod_timer. > > was this tested? No. But compiles fine. From shmulik.hen@intel.com Thu Oct 2 00:57:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 00:58:32 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h927vw25015703 for ; Thu, 2 Oct 2003 00:57:59 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.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 h927rQfw024445 for ; Thu, 2 Oct 2003 07:53:26 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.fm.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 h927vM125645 for ; Thu, 2 Oct 2003 07:57:22 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003100200574817781 ; Thu, 02 Oct 2003 00:57:49 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: Subject: Re: [Bonding-devel] Re: [bonding] compatibilty issues Date: Thu, 2 Oct 2003 10:57:46 +0300 User-Agent: KMail/1.4.3 References: In-Reply-To: Cc: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200310021057.46995.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 445 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Content-Length: 1348 Lines: 34 I wrote: > * Created a version for 2.4 that puts back all old compatibility > stuff that was removed either during the propagation set or the > cleanup set. > * Created a version for 2.6 that puts back just the compatibility > stuff that was removed in the propagation set (BOND_SETHWADDR, > since we got a complaint from a RH9 user). Jeff, I'm going to need a ruling from you: We understood from David that support of old ioctl definitions (i.e. those mapped to SIOCDEVPRIVATE) needs to be removed in the 2.6 kernel. This will break compatibility with old versions of ifenslave (at least 2 years old, but still included in recent distributions like Red Hat 9). If removing those private ioctls is a necessity for 2.6, then breaking compatibility with the old ifenslave versions is inevitable, so we might as well remove all compatibility stuff from the 2.6 bonding module (not just the private ioctls). Of course, we'll keep ifenslave fully compatible with all versions of bonding, so the user only needs to upgrade the tool once. Given the above, how do you feel about removing old backward compatibility stuff from bonding in 2.6 ? -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From davem@pizda.ninka.net Thu Oct 2 01:40:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 01:41:09 -0700 (PDT) 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 h928eZ25018795 for ; Thu, 2 Oct 2003 01:40:35 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id BAA10215; Thu, 2 Oct 2003 01:36:20 -0700 Date: Thu, 2 Oct 2003 01:36:20 -0700 From: "David S. Miller" To: Vinay K Nallamothu Cc: akpm@osdl.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2.6.0-test6][X25] timer cleanup Message-Id: <20031002013620.6d8b6f10.davem@redhat.com> In-Reply-To: <1065078208.4340.3.camel@lima.royalchallenge.com> References: <1065018387.7194.336.camel@lima.royalchallenge.com> <20031001155623.06b89258.akpm@osdl.org> <1065078208.4340.3.camel@lima.royalchallenge.com> X-Mailer: Sylpheed version 0.9.2 (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: 446 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 Content-Length: 446 Lines: 15 On Thu, 02 Oct 2003 12:33:28 +0530 Vinay K Nallamothu wrote: > On Thu, 2003-10-02 at 04:26, Andrew Morton wrote: > > Vinay K Nallamothu wrote: > > > > > > Replace del_timer, mod_timer sequences with mod_timer. > > > > was this tested? > No. But compiles fine. Please find a way to at least minimally test the protocols you are changing then, or find someone else who can. Thanks. From davem@pizda.ninka.net Thu Oct 2 01:41:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 01:41:49 -0700 (PDT) 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 h928fF25018863 for ; Thu, 2 Oct 2003 01:41:16 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id BAA10232; Thu, 2 Oct 2003 01:37:04 -0700 Date: Thu, 2 Oct 2003 01:37:03 -0700 From: "David S. Miller" To: Vinay K Nallamothu Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2.6.0-test6][ROSE] timer cleanups (and couple of fixes) Message-Id: <20031002013703.5072c707.davem@redhat.com> In-Reply-To: <1065017300.7194.318.camel@lima.royalchallenge.com> References: <1065017300.7194.318.camel@lima.royalchallenge.com> X-Mailer: Sylpheed version 0.9.2 (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: 447 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 Content-Length: 204 Lines: 5 I'm going to assume this one is not even minimally tested either just like your X25 timer changes, and likewise I want you to find a method to get the changes tested before I add the changes to my tree. From davem@pizda.ninka.net Thu Oct 2 01:52:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 01:53:22 -0700 (PDT) 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 h928ql25027606 for ; Thu, 2 Oct 2003 01:52:48 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id BAA10281; Thu, 2 Oct 2003 01:48:38 -0700 Date: Thu, 2 Oct 2003 01:48:38 -0700 From: "David S. Miller" To: Burton Windle Cc: netdev@oss.sgi.com Subject: Re: [RFC] Silencing needless printk in socket.c Message-Id: <20031002014838.0c790cda.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (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: 448 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 Content-Length: 849 Lines: 21 On Wed, 1 Oct 2003 14:41:09 -0400 (EDT) Burton Windle wrote: > Would anyone object to a patch that wraps the printk in > linux/net/socket.c:1897 in a 'if debug'? > > This first appeared around 2.6.0-test5; the output may be helpful to a > developer, but I don't think it is needed in the normal dmesg. Yes it is needed, and since in the same changes that _ADDED_ this new printk I _REMOVED_ all the numerous per-protocol printks that were printed out. Less stuff is printed out now than before, and now this is the only indication that a particular protocol family got registered or unregistered successfully. We're not removing this. This is especially the case beause people like you didn't complain at all when we used to get 4 or 5 lines of printk messages for each of these protocols when they started up or shut down. From Robert.Olsson@data.slu.se Thu Oct 2 09:33:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 09:34:34 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92GXs25025049 for ; Thu, 2 Oct 2003 09:33:55 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.9.3+/8.9.3) with ESMTP id RAA23142; Thu, 2 Oct 2003 17:31:29 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id DDFBAEC22F; Thu, 2 Oct 2003 17:31:30 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16252.17618.866515.952549@robur.slu.se> Date: Thu, 2 Oct 2003 17:31:30 +0200 To: Jeff Garzik Cc: Robert Olsson , Andrew Morton , netdev@oss.sgi.com, dfages@arkoon.net Subject: Re: Fw: [BUG/PATCH] CONFIG_NET_HW_FLOWCONTROL and SMP In-Reply-To: <3F78A691.1040406@pobox.com> References: <20030929123734.5bd97a47.akpm@osdl.org> <16248.41796.797321.700866@robur.slu.se> <3F78A691.1040406@pobox.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-archive-position: 449 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 27030 Lines: 773 Jeff Garzik writes: > > If someone had a NAPI patch for tulip, we could remove HW_FLOWCONTROL > option altogether :) Hello! Here is something for 2.6.0-test6: * ifdef's to keep current non-NAPI tulip intact * Port based on Alexey's orig NAPI tulip design (Only RX handled by dev->poll) * tulip HW_FLOW removed * NAPI and HW-mitigation options in Kconfig Cheers --ro --- drivers/net/tulip.orig/Kconfig 2003-09-28 02:50:39.000000000 +0200 +++ drivers/net/tulip/Kconfig 2003-09-30 14:34:39.000000000 +0200 @@ -68,6 +68,26 @@ obscure bugs if your mainboard has memory controller timing issues. If in doubt, say N. +config TULIP_NAPI + bool "Use NAPI RX polling " + depends on TULIP + ---help--- + This is of useful for servers and routers dealing with high network loads. + + See . + + If in doubt, say N. + +config TULIP_NAPI_HW_MITIGATION + bool "Use Interrupt Mitigation " + depends on TULIP_NAPI + ---help--- + Use HW to reduce RX interrupts. Not strict necessary since NAPI reduces + RX interrupts but itself. Although this reduces RX interrupts even at + low levels traffic at the cost of a small latency. + + If in doubt, say Y. + config DE4X5 tristate "Generic DECchip & DIGITAL EtherWORKS PCI/EISA" depends on NET_TULIP && (PCI || EISA) --- drivers/net/tulip.orig/tulip.h 2003-09-28 02:51:02.000000000 +0200 +++ drivers/net/tulip/tulip.h 2003-09-30 14:22:08.000000000 +0200 @@ -126,6 +126,7 @@ CFDD_Snooze = (1 << 30), }; +#define RxPollInt (RxIntr|RxNoBuf|RxDied|RxJabber) /* The bits in the CSR5 status registers, mostly interrupt sources. */ enum status_bits { @@ -251,9 +252,9 @@ Making the Tx ring too large decreases the effectiveness of channel bonding and packet priority. There are no ill effects from too-large receive rings. */ -#define TX_RING_SIZE 16 -#define RX_RING_SIZE 32 +#define TX_RING_SIZE 32 +#define RX_RING_SIZE 128 #define MEDIA_MASK 31 #define PKT_BUF_SZ 1536 /* Size of each temporary Rx buffer. */ @@ -343,17 +344,15 @@ int flags; struct net_device_stats stats; struct timer_list timer; /* Media selection timer. */ + struct timer_list oom_timer; /* Out of memory timer. */ u32 mc_filter[2]; spinlock_t lock; spinlock_t mii_lock; unsigned int cur_rx, cur_tx; /* The next free ring entry */ unsigned int dirty_rx, dirty_tx; /* The ring entries to be free()ed. */ -#ifdef CONFIG_NET_HW_FLOWCONTROL -#define RX_A_NBF_STOP 0xffffff3f /* To disable RX and RX-NOBUF ints. */ - int fc_bit; - int mit_sel; - int mit_change; /* Signal for Interrupt Mitigtion */ +#ifdef CONFIG_TULIP_NAPI_HW_MITIGATION + int mit_on; #endif unsigned int full_duplex:1; /* Full-duplex operation requested. */ unsigned int full_duplex_lock:1; @@ -415,6 +414,10 @@ extern int tulip_rx_copybreak; irqreturn_t tulip_interrupt(int irq, void *dev_instance, struct pt_regs *regs); int tulip_refill_rx(struct net_device *dev); +#ifdef CONFIG_TULIP_NAPI +int tulip_poll(struct net_device *dev, int *budget); +#endif + /* media.c */ int tulip_mdio_read(struct net_device *dev, int phy_id, int location); @@ -438,6 +441,7 @@ extern const char * const medianame[]; extern const char tulip_media_cap[]; extern struct tulip_chip_table tulip_tbl[]; +void oom_timer(unsigned long data); extern u8 t21040_csr13[]; #ifndef USE_IO_OPS --- drivers/net/tulip.orig/tulip_core.c 2003-09-28 02:50:29.000000000 +0200 +++ drivers/net/tulip/tulip_core.c 2003-09-30 14:29:11.000000000 +0200 @@ -14,11 +14,17 @@ */ +#include + #define DRV_NAME "tulip" +#ifdef CONFIG_TULIP_NAPI +#define DRV_VERSION "1.1.13-NAPI" /* Keep at least for test */ +#else #define DRV_VERSION "1.1.13" +#endif #define DRV_RELDATE "May 11, 2002" -#include + #include #include "tulip.h" #include @@ -465,29 +471,16 @@ to an alternate media type. */ tp->timer.expires = RUN_AT(next_tick); add_timer(&tp->timer); -} - -#ifdef CONFIG_NET_HW_FLOWCONTROL -/* Enable receiver */ -void tulip_xon(struct net_device *dev) -{ - struct tulip_private *tp = (struct tulip_private *)dev->priv; - - clear_bit(tp->fc_bit, &netdev_fc_xoff); - if (netif_running(dev)){ - - tulip_refill_rx(dev); - outl(tulip_tbl[tp->chip_id].valid_intrs, dev->base_addr+CSR7); - } -} +#ifdef CONFIG_TULIP_NAPI + init_timer(&tp->oom_timer); + tp->oom_timer.data = (unsigned long)dev; + tp->oom_timer.function = oom_timer; #endif +} static int tulip_open(struct net_device *dev) { -#ifdef CONFIG_NET_HW_FLOWCONTROL - struct tulip_private *tp = (struct tulip_private *)dev->priv; -#endif int retval; if ((retval = request_irq(dev->irq, &tulip_interrupt, SA_SHIRQ, dev->name, dev))) @@ -497,10 +490,6 @@ tulip_up (dev); -#ifdef CONFIG_NET_HW_FLOWCONTROL - tp->fc_bit = netdev_register_fc(dev, tulip_xon); -#endif - netif_start_queue (dev); return 0; @@ -581,10 +570,7 @@ #endif /* Stop and restart the chip's Tx processes . */ -#ifdef CONFIG_NET_HW_FLOWCONTROL - if (tp->fc_bit && test_bit(tp->fc_bit,&netdev_fc_xoff)) - printk("BUG tx_timeout restarting rx when fc on\n"); -#endif + tulip_restart_rxtx(tp); /* Trigger an immediate transmit demand. */ outl(0, ioaddr + CSR1); @@ -741,7 +727,9 @@ unsigned long flags; del_timer_sync (&tp->timer); - +#ifdef CONFIG_TULIP_NAPI + del_timer_sync (&tp->oom_timer); +#endif spin_lock_irqsave (&tp->lock, flags); /* Disable interrupts by clearing the interrupt mask. */ @@ -780,13 +768,6 @@ netif_stop_queue (dev); -#ifdef CONFIG_NET_HW_FLOWCONTROL - if (tp->fc_bit) { - int bit = tp->fc_bit; - tp->fc_bit = 0; - netdev_unregister_fc(bit); - } -#endif tulip_down (dev); if (tulip_debug > 1) @@ -1627,6 +1608,10 @@ dev->hard_start_xmit = tulip_start_xmit; dev->tx_timeout = tulip_tx_timeout; dev->watchdog_timeo = TX_TIMEOUT; +#ifdef CONFIG_TULIP_NAPI + dev->poll = tulip_poll; + dev->weight = 16; +#endif dev->stop = tulip_close; dev->get_stats = tulip_get_stats; dev->do_ioctl = private_ioctl; --- drivers/net/tulip.orig/interrupt.c 2003-09-28 02:50:14.000000000 +0200 +++ drivers/net/tulip/interrupt.c 2003-09-30 17:47:12.000000000 +0200 @@ -19,13 +19,13 @@ #include #include - int tulip_rx_copybreak; unsigned int tulip_max_interrupt_work; -#ifdef CONFIG_NET_HW_FLOWCONTROL - +#ifdef CONFIG_TULIP_NAPI_HW_MITIGATION #define MIT_SIZE 15 +#define MIT_TABLE 15 /* We use 0 or max */ + unsigned int mit_table[MIT_SIZE+1] = { /* CRS11 21143 hardware Mitigation Control Interrupt @@ -99,16 +99,25 @@ return refilled; } +#ifdef CONFIG_TULIP_NAPI -static int tulip_rx(struct net_device *dev) +void oom_timer(unsigned long data) +{ + struct net_device *dev = (struct net_device *)data; + netif_rx_schedule(dev); +} + +int tulip_poll(struct net_device *dev, int *budget) { struct tulip_private *tp = (struct tulip_private *)dev->priv; int entry = tp->cur_rx % RX_RING_SIZE; - int rx_work_limit = tp->dirty_rx + RX_RING_SIZE - tp->cur_rx; + int rx_work_limit = *budget; int received = 0; -#ifdef CONFIG_NET_HW_FLOWCONTROL - int drop = 0, mit_sel = 0; + if (rx_work_limit > dev->quota) + rx_work_limit = dev->quota; + +#ifdef CONFIG_TULIP_NAPI_HW_MITIGATION /* that one buffer is needed for mit activation; or might be a bug in the ring buffer code; check later -- JHS*/ @@ -119,6 +128,237 @@ if (tulip_debug > 4) printk(KERN_DEBUG " In tulip_rx(), entry %d %8.8x.\n", entry, tp->rx_ring[entry].status); + + do { + /* Acknowledge current RX interrupt sources. */ + outl((RxIntr | RxNoBuf), dev->base_addr + CSR5); + + + /* If we own the next entry, it is a new packet. Send it up. */ + while ( ! (tp->rx_ring[entry].status & cpu_to_le32(DescOwned))) { + s32 status = le32_to_cpu(tp->rx_ring[entry].status); + + + if (tp->dirty_rx + RX_RING_SIZE == tp->cur_rx) + break; + + if (tulip_debug > 5) + printk(KERN_DEBUG "%s: In tulip_rx(), entry %d %8.8x.\n", + dev->name, entry, status); + if (--rx_work_limit < 0) + goto not_done; + + if ((status & 0x38008300) != 0x0300) { + if ((status & 0x38000300) != 0x0300) { + /* Ingore earlier buffers. */ + if ((status & 0xffff) != 0x7fff) { + if (tulip_debug > 1) + printk(KERN_WARNING "%s: Oversized Ethernet frame " + "spanned multiple buffers, status %8.8x!\n", + dev->name, status); + tp->stats.rx_length_errors++; + } + } else if (status & RxDescFatalErr) { + /* There was a fatal error. */ + if (tulip_debug > 2) + printk(KERN_DEBUG "%s: Receive error, Rx status %8.8x.\n", + dev->name, status); + tp->stats.rx_errors++; /* end of a packet.*/ + if (status & 0x0890) tp->stats.rx_length_errors++; + if (status & 0x0004) tp->stats.rx_frame_errors++; + if (status & 0x0002) tp->stats.rx_crc_errors++; + if (status & 0x0001) tp->stats.rx_fifo_errors++; + } + } else { + /* Omit the four octet CRC from the length. */ + short pkt_len = ((status >> 16) & 0x7ff) - 4; + struct sk_buff *skb; + +#ifndef final_version + if (pkt_len > 1518) { + printk(KERN_WARNING "%s: Bogus packet size of %d (%#x).\n", + dev->name, pkt_len, pkt_len); + pkt_len = 1518; + tp->stats.rx_length_errors++; + } +#endif + /* Check if the packet is long enough to accept without copying + to a minimally-sized skbuff. */ + if (pkt_len < tulip_rx_copybreak + && (skb = dev_alloc_skb(pkt_len + 2)) != NULL) { + skb->dev = dev; + skb_reserve(skb, 2); /* 16 byte align the IP header */ + pci_dma_sync_single(tp->pdev, + tp->rx_buffers[entry].mapping, + pkt_len, PCI_DMA_FROMDEVICE); +#if ! defined(__alpha__) + eth_copy_and_sum(skb, tp->rx_buffers[entry].skb->tail, + pkt_len, 0); + skb_put(skb, pkt_len); +#else + memcpy(skb_put(skb, pkt_len), + tp->rx_buffers[entry].skb->tail, + pkt_len); +#endif + } else { /* Pass up the skb already on the Rx ring. */ + char *temp = skb_put(skb = tp->rx_buffers[entry].skb, + pkt_len); + +#ifndef final_version + if (tp->rx_buffers[entry].mapping != + le32_to_cpu(tp->rx_ring[entry].buffer1)) { + printk(KERN_ERR "%s: Internal fault: The skbuff addresses " + "do not match in tulip_rx: %08x vs. %08x %p / %p.\n", + dev->name, + le32_to_cpu(tp->rx_ring[entry].buffer1), + tp->rx_buffers[entry].mapping, + skb->head, temp); + } +#endif + + pci_unmap_single(tp->pdev, tp->rx_buffers[entry].mapping, + PKT_BUF_SZ, PCI_DMA_FROMDEVICE); + + tp->rx_buffers[entry].skb = NULL; + tp->rx_buffers[entry].mapping = 0; + } + skb->protocol = eth_type_trans(skb, dev); + + netif_receive_skb(skb); + + dev->last_rx = jiffies; + tp->stats.rx_packets++; + tp->stats.rx_bytes += pkt_len; + } + received++; + + entry = (++tp->cur_rx) % RX_RING_SIZE; + if (tp->cur_rx - tp->dirty_rx > RX_RING_SIZE/4) + tulip_refill_rx(dev); + + } + + /* New ack strategy... irq does not ack Rx any longer + hopefully this helps */ + + /* Really bad things can happen here... If new packet arrives + * and an irq arrives (tx or just due to occasionally unset + * mask), it will be acked by irq handler, but new thread + * is not scheduled. It is major hole in design. + * No idea how to fix this if "playing with fire" will fail + * tomorrow (night 011029). If it will not fail, we won + * finally: amount of IO did not increase at all. */ + } while ((inl(dev->base_addr + CSR5) & RxIntr)); + + /* done: */ + + #ifdef CONFIG_TULIP_NAPI_HW_MITIGATION + + /* We use this simplistic scheme for IM. It's proven by + real life installations. We can have IM enabled + continuesly but this would cause unnecessary latency. + Unfortunely we can't use all the NET_RX_* feedback here. + This would turn on IM for devices that is not contributing + to backlog congestion with unnecessary latency. + + We monitor the the device RX-ring and have: + + HW Interrupt Mitigation either ON or OFF. + + ON: More then 1 pkt received (per intr.) OR we are dropping + OFF: Only 1 pkt received + + Note. We only use min and max (0, 15) settings from mit_table */ + + + if( tp->flags & HAS_INTR_MITIGATION) { + if( received > 1 ) { + if( ! tp->mit_on ) { + tp->mit_on = 1; + outl(mit_table[MIT_TABLE], dev->base_addr + CSR11); + } + } + else { + if( tp->mit_on ) { + tp->mit_on = 0; + outl(0, dev->base_addr + CSR11); + } + } + } + +#endif /* CONFIG_TULIP_NAPI_HW_MITIGATION */ + + dev->quota -= received; + *budget -= received; + + tulip_refill_rx(dev); + + /* If RX ring is not full we are out of memory. */ + if (tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL) goto oom; + + /* Remove us from polling list and enable RX intr. */ + + netif_rx_complete(dev); + outl(tulip_tbl[tp->chip_id].valid_intrs, dev->base_addr+CSR7); + + /* The last op happens after poll completion. Which means the following: + * 1. it can race with disabling irqs in irq handler + * 2. it can race with dise/enabling irqs in other poll threads + * 3. if an irq raised after beginning loop, it will be immediately + * triggered here. + * + * Summarizing: the logic results in some redundant irqs both + * due to races in masking and due to too late acking of already + * processed irqs. But it must not result in losing events. + */ + + return 0; + + not_done: + if (!received) { + + received = dev->quota; /* Not to happen */ + } + dev->quota -= received; + *budget -= received; + + if (tp->cur_rx - tp->dirty_rx > RX_RING_SIZE/2 || + tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL) + tulip_refill_rx(dev); + + if (tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL) goto oom; + + return 1; + + + oom: /* Executed with RX ints disabled */ + + + /* Start timer, stop polling, but do not enable rx interrupts. */ + mod_timer(&tp->oom_timer, jiffies+1); + + /* Think: timer_pending() was an explicit signature of bug. + * Timer can be pending now but fired and completed + * before we did netif_rx_complete(). See? We would lose it. */ + + /* remove ourselves from the polling list */ + netif_rx_complete(dev); + + return 0; +} + +#else /* CONFIG_TULIP_NAPI */ + +static int tulip_rx(struct net_device *dev) +{ + struct tulip_private *tp = (struct tulip_private *)dev->priv; + int entry = tp->cur_rx % RX_RING_SIZE; + int rx_work_limit = tp->dirty_rx + RX_RING_SIZE - tp->cur_rx; + int received = 0; + + if (tulip_debug > 4) + printk(KERN_DEBUG " In tulip_rx(), entry %d %8.8x.\n", entry, + tp->rx_ring[entry].status); /* If we own the next entry, it is a new packet. Send it up. */ while ( ! (tp->rx_ring[entry].status & cpu_to_le32(DescOwned))) { s32 status = le32_to_cpu(tp->rx_ring[entry].status); @@ -163,11 +403,6 @@ } #endif -#ifdef CONFIG_NET_HW_FLOWCONTROL - drop = atomic_read(&netdev_dropping); - if (drop) - goto throttle; -#endif /* Check if the packet is long enough to accept without copying to a minimally-sized skbuff. */ if (pkt_len < tulip_rx_copybreak @@ -209,44 +444,9 @@ tp->rx_buffers[entry].mapping = 0; } skb->protocol = eth_type_trans(skb, dev); -#ifdef CONFIG_NET_HW_FLOWCONTROL - mit_sel = -#endif - netif_rx(skb); -#ifdef CONFIG_NET_HW_FLOWCONTROL - switch (mit_sel) { - case NET_RX_SUCCESS: - case NET_RX_CN_LOW: - case NET_RX_CN_MOD: - break; - - case NET_RX_CN_HIGH: - rx_work_limit -= NET_RX_CN_HIGH; /* additional*/ - break; - case NET_RX_DROP: - rx_work_limit = -1; - break; - default: - printk("unknown feedback return code %d\n", mit_sel); - break; - } + netif_rx(skb); - drop = atomic_read(&netdev_dropping); - if (drop) { -throttle: - rx_work_limit = -1; - mit_sel = NET_RX_DROP; - - if (tp->fc_bit) { - long ioaddr = dev->base_addr; - - /* disable Rx & RxNoBuf ints. */ - outl(tulip_tbl[tp->chip_id].valid_intrs&RX_A_NBF_STOP, ioaddr + CSR7); - set_bit(tp->fc_bit, &netdev_fc_xoff); - } - } -#endif dev->last_rx = jiffies; tp->stats.rx_packets++; tp->stats.rx_bytes += pkt_len; @@ -254,42 +454,9 @@ received++; entry = (++tp->cur_rx) % RX_RING_SIZE; } -#ifdef CONFIG_NET_HW_FLOWCONTROL - - /* We use this simplistic scheme for IM. It's proven by - real life installations. We can have IM enabled - continuesly but this would cause unnecessary latency. - Unfortunely we can't use all the NET_RX_* feedback here. - This would turn on IM for devices that is not contributing - to backlog congestion with unnecessary latency. - - We monitor the device RX-ring and have: - - HW Interrupt Mitigation either ON or OFF. - - ON: More then 1 pkt received (per intr.) OR we are dropping - OFF: Only 1 pkt received - - Note. We only use min and max (0, 15) settings from mit_table */ - - - if( tp->flags & HAS_INTR_MITIGATION) { - if((received > 1 || mit_sel == NET_RX_DROP) - && tp->mit_sel != 15 ) { - tp->mit_sel = 15; - tp->mit_change = 1; /* Force IM change */ - } - if((received <= 1 && mit_sel != NET_RX_DROP) && tp->mit_sel != 0 ) { - tp->mit_sel = 0; - tp->mit_change = 1; /* Force IM change */ - } - } - - return RX_RING_SIZE+1; /* maxrx+1 */ -#else return received; -#endif } +#endif /* CONFIG_TULIP_NAPI */ static inline unsigned int phy_interrupt (struct net_device *dev) { @@ -323,7 +490,6 @@ struct tulip_private *tp = (struct tulip_private *)dev->priv; long ioaddr = dev->base_addr; int csr5; - int entry; int missed; int rx = 0; int tx = 0; @@ -331,6 +497,11 @@ int maxrx = RX_RING_SIZE; int maxtx = TX_RING_SIZE; int maxoi = TX_RING_SIZE; +#ifdef CONFIG_TULIP_NAPI + int rxd = 0; +#else + int entry; +#endif unsigned int work_count = tulip_max_interrupt_work; unsigned int handled = 0; @@ -346,22 +517,41 @@ tp->nir++; do { + +#ifdef CONFIG_TULIP_NAPI + + if (!rxd && (csr5 & (RxIntr | RxNoBuf))) { + rxd++; + /* Mask RX intrs and add the device to poll list. */ + outl(tulip_tbl[tp->chip_id].valid_intrs&~RxPollInt, ioaddr + CSR7); + netif_rx_schedule(dev); + + if (!(csr5&~(AbnormalIntr|NormalIntr|RxPollInt|TPLnkPass))) + break; + } + + /* Acknowledge the interrupt sources we handle here ASAP + the poll function does Rx and RxNoBuf acking */ + + outl(csr5 & 0x0001ff3f, ioaddr + CSR5); + +#else /* Acknowledge all of the current interrupt sources ASAP. */ outl(csr5 & 0x0001ffff, ioaddr + CSR5); - if (tulip_debug > 4) - printk(KERN_DEBUG "%s: interrupt csr5=%#8.8x new csr5=%#8.8x.\n", - dev->name, csr5, inl(dev->base_addr + CSR5)); if (csr5 & (RxIntr | RxNoBuf)) { -#ifdef CONFIG_NET_HW_FLOWCONTROL - if ((!tp->fc_bit) || - (!test_bit(tp->fc_bit, &netdev_fc_xoff))) -#endif rx += tulip_rx(dev); tulip_refill_rx(dev); } +#endif /* CONFIG_TULIP_NAPI */ + + if (tulip_debug > 4) + printk(KERN_DEBUG "%s: interrupt csr5=%#8.8x new csr5=%#8.8x.\n", + dev->name, csr5, inl(dev->base_addr + CSR5)); + + if (csr5 & (TxNoBuf | TxDied | TxIntr | TimerInt)) { unsigned int dirty_tx; @@ -462,15 +652,8 @@ } if (csr5 & RxDied) { /* Missed a Rx frame. */ tp->stats.rx_missed_errors += inl(ioaddr + CSR8) & 0xffff; -#ifdef CONFIG_NET_HW_FLOWCONTROL - if (tp->fc_bit && !test_bit(tp->fc_bit, &netdev_fc_xoff)) { - tp->stats.rx_errors++; - tulip_start_rxtx(tp); - } -#else tp->stats.rx_errors++; tulip_start_rxtx(tp); -#endif } /* * NB: t21142_lnk_change() does a del_timer_sync(), so be careful if this @@ -504,10 +687,6 @@ if (tulip_debug > 2) printk(KERN_ERR "%s: Re-enabling interrupts, %8.8x.\n", dev->name, csr5); -#ifdef CONFIG_NET_HW_FLOWCONTROL - if (tp->fc_bit && (test_bit(tp->fc_bit, &netdev_fc_xoff))) - if (net_ratelimit()) printk("BUG!! enabling interrupt when FC off (timerintr.) \n"); -#endif outl(tulip_tbl[tp->chip_id].valid_intrs, ioaddr + CSR7); tp->ttimer = 0; oi++; @@ -520,16 +699,9 @@ /* Acknowledge all interrupt sources. */ outl(0x8001ffff, ioaddr + CSR5); if (tp->flags & HAS_INTR_MITIGATION) { -#ifdef CONFIG_NET_HW_FLOWCONTROL - if(tp->mit_change) { - outl(mit_table[tp->mit_sel], ioaddr + CSR11); - tp->mit_change = 0; - } -#else /* Josip Loncaric at ICASE did extensive experimentation to develop a good interrupt mitigation setting.*/ outl(0x8b240000, ioaddr + CSR11); -#endif } else if (tp->chip_id == LC82C168) { /* the LC82C168 doesn't have a hw timer.*/ outl(0x00, ioaddr + CSR7); @@ -537,10 +709,8 @@ } else { /* Mask all interrupting sources, set timer to re-enable. */ -#ifndef CONFIG_NET_HW_FLOWCONTROL outl(((~csr5) & 0x0001ebef) | AbnormalIntr | TimerInt, ioaddr + CSR7); outl(0x0012, ioaddr + CSR11); -#endif } break; } @@ -550,6 +720,21 @@ break; csr5 = inl(ioaddr + CSR5); + +#ifdef CONFIG_TULIP_NAPI + if (rxd) + csr5 &= ~RxPollInt; + } while ((csr5 & (TxNoBuf | + TxDied | + TxIntr | + TimerInt | + /* Abnormal intr. */ + RxDied | + TxFIFOUnderflow | + TxJabber | + TPLnkFail | + SytemError )) != 0); +#else } while ((csr5 & (NormalIntr|AbnormalIntr)) != 0); tulip_refill_rx(dev); @@ -574,6 +759,7 @@ } } } +#endif /* CONFIG_TULIP_NAPI */ if ((missed = inl(ioaddr + CSR8) & 0x1ffff)) { tp->stats.rx_dropped += missed & 0x10000 ? 0x10000 : missed; From modica@sgi.com Thu Oct 2 09:55:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 09:55:42 -0700 (PDT) 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 h92Gt525027294 for ; Thu, 2 Oct 2003 09:55:06 -0700 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 h92HCQHc011164 for ; Thu, 2 Oct 2003 12:12:26 -0500 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 h92Gsxcc11891621 for ; Thu, 2 Oct 2003 11:54:59 -0500 (CDT) 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 h92GsxRn308943498 for ; Thu, 2 Oct 2003 11:54:59 -0500 (CDT) Message-ID: <3F7C5863.1080403@sgi.com> Date: Thu, 02 Oct 2003 11:54:59 -0500 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: mod_timer improvement Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 450 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 This improves mod_timer scaling quite drastically. It's already in the 2.6 kernel. I've been testing with 8 cpus, 8 threads and 8 cards and mod_timer ends up taking up more time than tg_poll without this change. *** /hosts/bonnie.engr.sgi.com//proj/sgilinux/lbs/isms/linux/linux/kernel/timer.c 2003/08/11 20:16:19 1.23 --- /hosts/bonnie.engr.sgi.com//proj/sgilinux/lbs/isms/linux/linux/kernel/timer.c 2003/10/01 21:09:20 1.24 *************** *** 207,212 **** --- 207,220 ---- int ret; unsigned long flags; + /* + * This is a common optimization triggered by the + * networking code - if the timer is re-modified + * to be the same thing then just return: + */ + if (timer->expires == expires && timer_pending(timer)) + return 1; + spin_lock_irqsave(&timerlist_lock, flags); timer->expires = expires; ret = detach_timer(timer); -- Steve Modica work: 651-683-3224 mobile: 651-261-3201 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 modica@sgi.com Thu Oct 2 10:15:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 10:15:54 -0700 (PDT) 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 h92HFK25028936 for ; Thu, 2 Oct 2003 10:15:20 -0700 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 h92FInOO020206 for ; Thu, 2 Oct 2003 08:18:49 -0700 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 h92HFEcc11874929 for ; Thu, 2 Oct 2003 12:15:14 -0500 (CDT) 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 h92HFERn310812056 for ; Thu, 2 Oct 2003 12:15:15 -0500 (CDT) Message-ID: <3F7C5D22.7010103@sgi.com> Date: Thu, 02 Oct 2003 12:15:14 -0500 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: Re: mod_timer improvement References: <3F7C5863.1080403@sgi.com> In-Reply-To: <3F7C5863.1080403@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 451 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 D'OH! Sorry about the formatting. I think this is better: @@ -207,6 +207,14 @@ int ret; unsigned long flags; + /* + * This is a common optimization triggered by the + * networking code - if the timer is re-modified + * to be the same thing then just return: + */ + if (timer->expires == expires && timer_pending(timer)) + return 1; + spin_lock_irqsave(&timerlist_lock, flags); timer->expires = expires; ret = detach_timer(timer); -- Steve Modica work: 651-683-3224 mobile: 651-261-3201 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 shemminger@osdl.org Thu Oct 2 10:24:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 10:25:29 -0700 (PDT) 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 h92HOu25029827 for ; Thu, 2 Oct 2003 10:24:57 -0700 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 h92HOj126072; Thu, 2 Oct 2003 10:24:45 -0700 Date: Thu, 2 Oct 2003 10:24:20 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] skbuff more likely/unlikely Message-Id: <20031002102420.6e1cece9.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 452 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 A couple more places where we can help by hinting the compiler for 2.6.0-test6. If we are pulling off header, is is likely there; and skb alloc's succeed in the normal case. Thought I saw an earlier similar patch, but here is my take on it. diff -Nru a/include/linux/skbuff.h b/include/linux/skbuff.h --- a/include/linux/skbuff.h Thu Oct 2 10:01:36 2003 +++ b/include/linux/skbuff.h Thu Oct 2 10:01:36 2003 @@ -885,7 +885,7 @@ */ static inline unsigned char *skb_pull(struct sk_buff *skb, unsigned int len) { - return (len > skb->len) ? NULL : __skb_pull(skb, len); + return unlikely(len > skb->len) ? NULL : __skb_pull(skb, len); } extern unsigned char *__pskb_pull_tail(struct sk_buff *skb, int delta); @@ -901,7 +901,7 @@ static inline unsigned char *pskb_pull(struct sk_buff *skb, unsigned int len) { - return (len > skb->len) ? NULL : __pskb_pull(skb, len); + return unlikely(len > skb->len) ? NULL : __pskb_pull(skb, len); } static inline int pskb_may_pull(struct sk_buff *skb, unsigned int len) @@ -1052,7 +1052,7 @@ int gfp_mask) { struct sk_buff *skb = alloc_skb(length + 16, gfp_mask); - if (skb) + if (likely(skb)) skb_reserve(skb, 16); return skb; } From shemminger@osdl.org Thu Oct 2 10:47:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 10:47:36 -0700 (PDT) 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 h92Hl225032662 for ; Thu, 2 Oct 2003 10:47:03 -0700 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 h92HLw125704; Thu, 2 Oct 2003 10:21:58 -0700 Date: Thu, 2 Oct 2003 10:21:33 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] consolidate skb delivery Message-Id: <20031002102133.7285b5ee.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 453 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 Several places all have the same code for delivering skb's to protocols. Consolidate into one inline function and give preference to new protocols. diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Thu Oct 2 10:01:13 2003 +++ b/net/core/dev.c Thu Oct 2 10:01:13 2003 @@ -1489,6 +1489,18 @@ } } +static __inline__ int deliver_skb(struct sk_buff *skb, + struct packet_type *pt_prev, int last) +{ + if (unlikely(!pt_prev->data)) + return deliver_to_old_ones(pt_prev, skb, last); + else { + atomic_inc(&skb->users); + return pt_prev->func(skb, skb->dev, pt_prev); + } +} + + #if defined(CONFIG_BRIDGE) || defined (CONFIG_BRIDGE_MODULE) int (*br_handle_frame_hook)(struct sk_buff *skb); @@ -1496,15 +1508,8 @@ struct packet_type *pt_prev) { int ret = NET_RX_DROP; - - if (pt_prev) { - if (!pt_prev->data) - ret = deliver_to_old_ones(pt_prev, skb, 0); - else { - atomic_inc(&skb->users); - ret = pt_prev->func(skb, skb->dev, pt_prev); - } - } + if (pt_prev) + ret = deliver_skb(skb, pt_prev, 0); return ret; } @@ -1552,16 +1557,8 @@ rcu_read_lock(); list_for_each_entry_rcu(ptype, &ptype_all, list) { if (!ptype->dev || ptype->dev == skb->dev) { - if (pt_prev) { - if (!pt_prev->data) { - ret = deliver_to_old_ones(pt_prev, - skb, 0); - } else { - atomic_inc(&skb->users); - ret = pt_prev->func(skb, skb->dev, - pt_prev); - } - } + if (pt_prev) + ret = deliver_skb(skb, pt_prev, 0); pt_prev = ptype; } } @@ -1574,27 +1571,15 @@ list_for_each_entry_rcu(ptype, &ptype_base[ntohs(type)&15], list) { if (ptype->type == type && (!ptype->dev || ptype->dev == skb->dev)) { - if (pt_prev) { - if (!pt_prev->data) { - ret = deliver_to_old_ones(pt_prev, - skb, 0); - } else { - atomic_inc(&skb->users); - ret = pt_prev->func(skb, skb->dev, - pt_prev); - } - } + if (pt_prev) + ret = deliver_skb(skb, pt_prev, 0); pt_prev = ptype; } } - if (pt_prev) { - if (!pt_prev->data) { - ret = deliver_to_old_ones(pt_prev, skb, 1); - } else { - ret = pt_prev->func(skb, skb->dev, pt_prev); - } - } else { + if (pt_prev) + ret = deliver_skb(skb, pt_prev, 1); + else { kfree_skb(skb); /* Jamal, now you will not able to escape explaining * me how you were going to use this. :-) From modica@sgi.com Thu Oct 2 11:20:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 11:21:04 -0700 (PDT) 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 h92IKT25003783 for ; Thu, 2 Oct 2003 11:20:29 -0700 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 h92GNwOO025913 for ; Thu, 2 Oct 2003 09:23:59 -0700 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 h92IKNcc11906680 for ; Thu, 2 Oct 2003 13:20:23 -0500 (CDT) 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 h92IKNRn305041557 for ; Thu, 2 Oct 2003 13:20:23 -0500 (CDT) Message-ID: <3F7C6C67.4010300@sgi.com> Date: Thu, 02 Oct 2003 13:20:23 -0500 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: mod_timer improvement Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 454 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 Sorry about the screwed up formatting! I'm kinda new at this :) *** linux/linux/kernel/timer.c 2003/08/11 20:16:19 1.23 --- linux/linux/kernel/timer.c 2003/10/01 21:09:20 1.24 *************** int mod_timer(struct timer_list *timer, *** 207,212 **** --- 207,220 ---- int ret; unsigned long flags; + /* + * This is a common optimization triggered by the + * networking code - if the timer is re-modified + * to be the same thing then just return: + */ + if (timer->expires == expires && timer_pending(timer)) + return 1; + spin_lock_irqsave(&timerlist_lock, flags); timer->expires = expires; ret = detach_timer(timer); -- Steve Modica work: 651-683-3224 mobile: 651-261-3201 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 modica@sgi.com Thu Oct 2 11:32:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 11:33:06 -0700 (PDT) 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 h92IWW25004970 for ; Thu, 2 Oct 2003 11:32:33 -0700 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 h92InsHc013427 for ; Thu, 2 Oct 2003 13:49:54 -0500 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 h92IWRcc11904246 for ; Thu, 2 Oct 2003 13:32:27 -0500 (CDT) 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 h92IWRRn301871341 for ; Thu, 2 Oct 2003 13:32:27 -0500 (CDT) Message-ID: <3F7C6F3B.6070502@sgi.com> Date: Thu, 02 Oct 2003 13:32:27 -0500 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: do_gettimeofday Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 455 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 We've been doing some experiments here with large numbers of adapters on a 64p Linux system. When running 8 threads and 8 cpus, the do_gettimeofday code starts to use a lot of time. It turns out that if a driver does not timestamp an incoming packet, the upper layer will stamp it for you in PSCHED_GET_TIME(stamp). What happens then is multiple cpus start fighting over the cacheline for the system clock and things get bad. One possible solution to this is to have the driver do the stamp using xtime. A number of ATM drivers do this now. In testing, it helps a lot. Here's a sample diff for the tg3.c driver: =========================================================================== Index: linux/linux/drivers/net/tg3.c =========================================================================== --- /usr/tmp/TmpDir.8948-0/linux/linux/drivers/net/tg3.c_1.23 Thu Oct 2 13:30:21 2003 +++ linux/linux/drivers/net/tg3.c Wed Oct 1 14:27:54 2003 @@ -2019,6 +2019,7 @@ skb->ip_summed = CHECKSUM_NONE; skb->protocol = eth_type_trans(skb, tp->dev); + skb->stamp = xtime; #if TG3_VLAN_TAG_USED if (tp->vlgrp != NULL && desc->type_flags & RXD_FLAG_VLAN) { It's been suggested that we make this tuneable so it's easy to enable and disable. There was concern as to whether xtime would be accurate enough for all possible uses of ->stamp. Does anyone have any comments on this? Regards! Steve -- Steve Modica work: 651-683-3224 mobile: 651-261-3201 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 ak@suse.de Thu Oct 2 12:25:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 12:26:27 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92JPr25011660 for ; Thu, 2 Oct 2003 12:25:53 -0700 Received: from Hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 07488169A49A; Thu, 2 Oct 2003 21:25:47 +0200 (CEST) Date: Thu, 2 Oct 2003 21:25:46 +0200 From: Andi Kleen To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] consolidate skb delivery Message-ID: <20031002192546.GA29673@wotan.suse.de> References: <20031002102133.7285b5ee.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031002102133.7285b5ee.shemminger@osdl.org> X-archive-position: 456 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev > +static __inline__ int deliver_skb(struct sk_buff *skb, > + struct packet_type *pt_prev, int last) > +{ > + if (unlikely(!pt_prev->data)) > + return deliver_to_old_ones(pt_prev, skb, last); Are there even any old style protocols left? If not you could just make it BUG() -Andi From akpm@osdl.org Thu Oct 2 12:33:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 12:33:42 -0700 (PDT) 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 h92JX725012429 for ; Thu, 2 Oct 2003 12:33:08 -0700 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id h92JWs120542; Thu, 2 Oct 2003 12:32:54 -0700 Date: Thu, 2 Oct 2003 12:34:19 -0700 From: Andrew Morton To: Jeff Garzik Cc: Robert.Olsson@data.slu.se, netdev@oss.sgi.com, dfages@arkoon.net Subject: Re: Fw: [BUG/PATCH] CONFIG_NET_HW_FLOWCONTROL and SMP Message-Id: <20031002123419.31cdb98d.akpm@osdl.org> In-Reply-To: <3F7C64BC.7030701@pobox.com> References: <20030929123734.5bd97a47.akpm@osdl.org> <16248.41796.797321.700866@robur.slu.se> <3F78A691.1040406@pobox.com> <16252.17618.866515.952549@robur.slu.se> <3F7C64BC.7030701@pobox.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: 457 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 Jeff Garzik wrote: > > Andrew, would you be willing to merge this into -mm for some > simultaneous netwide testing? Sure. From shemminger@osdl.org Thu Oct 2 12:44:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 12:44:59 -0700 (PDT) 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 h92JiP25013467 for ; Thu, 2 Oct 2003 12:44:25 -0700 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 h92JiA122478; Thu, 2 Oct 2003 12:44:10 -0700 Date: Thu, 2 Oct 2003 12:43:45 -0700 From: Stephen Hemminger To: Andi Kleen Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] consolidate skb delivery Message-Id: <20031002124345.7b34bf24.shemminger@osdl.org> In-Reply-To: <20031002192546.GA29673@wotan.suse.de> References: <20031002102133.7285b5ee.shemminger@osdl.org> <20031002192546.GA29673@wotan.suse.de> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 458 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 Thu, 2 Oct 2003 21:25:46 +0200 Andi Kleen wrote: > > +static __inline__ int deliver_skb(struct sk_buff *skb, > > + struct packet_type *pt_prev, int last) > > +{ > > + if (unlikely(!pt_prev->data)) > > + return deliver_to_old_ones(pt_prev, skb, last); > > Are there even any old style protocols left? If not you could just make > it BUG() > bpqether,lapbether,ipconfig, and econet are still old style. From ak@suse.de Thu Oct 2 12:51:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 12:51:49 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92Jp525014579 for ; Thu, 2 Oct 2003 12:51:05 -0700 Received: from Hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id E1A6B169A51B; Thu, 2 Oct 2003 21:29:42 +0200 (CEST) Date: Thu, 2 Oct 2003 21:29:42 +0200 From: Andi Kleen To: Steve Modica Cc: netdev@oss.sgi.com Subject: Re: do_gettimeofday Message-ID: <20031002192942.GB29673@wotan.suse.de> References: <3F7C6F3B.6070502@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F7C6F3B.6070502@sgi.com> X-archive-position: 459 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Thu, Oct 02, 2003 at 01:32:27PM -0500, Steve Modica wrote: > We've been doing some experiments here with large numbers of adapters on a > 64p Linux system. > When running 8 threads and 8 cpus, the do_gettimeofday code starts to use a > lot of time. That's a known problem. The funny thing is that the only users of this time stamp is SO_TIMESTAMP, which is rarely used (except tcpdump) and something in DECnet. IMHO the right fix is to add a global counter that counts all all sockets that use SO_TIMESTAMP and when it's zero never call it. Decnet could be probably fixed to just use jiffies like TCP does. Drawback is that when you enable SO_TIMESTAMP there is a small time window when the packets are not time stamped yet. The socket layer can just fill in the current time though. -Andi From shemminger@osdl.org Thu Oct 2 12:57:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 12:58:10 -0700 (PDT) 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 h92JvX25015727 for ; Thu, 2 Oct 2003 12:57:36 -0700 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 h92Juo125121; Thu, 2 Oct 2003 12:56:50 -0700 Date: Thu, 2 Oct 2003 12:56:25 -0700 From: Stephen Hemminger To: Steve Modica Cc: netdev@oss.sgi.com Subject: Re: do_gettimeofday Message-Id: <20031002125625.72b8c0a7.shemminger@osdl.org> In-Reply-To: <3F7C6F3B.6070502@sgi.com> References: <3F7C6F3B.6070502@sgi.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 460 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 Thu, 02 Oct 2003 13:32:27 -0500 Steve Modica wrote: > We've been doing some experiments here with large numbers of adapters on a 64p Linux system. > > When running 8 threads and 8 cpus, the do_gettimeofday code starts to use a lot of time. > > It turns out that if a driver does not timestamp an incoming packet, the upper layer will stamp it for you in > PSCHED_GET_TIME(stamp). What happens then is multiple cpus start fighting over the cacheline for the system clock and things get bad. > > One possible solution to this is to have the driver do the stamp using xtime. A number of ATM drivers do this now. In testing, it helps a lot. > > Here's a sample diff for the tg3.c driver: > > =========================================================================== > Index: linux/linux/drivers/net/tg3.c > =========================================================================== > > --- /usr/tmp/TmpDir.8948-0/linux/linux/drivers/net/tg3.c_1.23 Thu Oct 2 13:30:21 2003 > +++ linux/linux/drivers/net/tg3.c Wed Oct 1 14:27:54 2003 > @@ -2019,6 +2019,7 @@ > skb->ip_summed = CHECKSUM_NONE; > > skb->protocol = eth_type_trans(skb, tp->dev); > + skb->stamp = xtime; > #if TG3_VLAN_TAG_USED > if (tp->vlgrp != NULL && > desc->type_flags & RXD_FLAG_VLAN) { > > > It's been suggested that we make this tuneable so it's easy to enable and disable. There was concern as to whether xtime would be accurate enough for all possible uses of ->stamp. > > Does anyone have any comments on this? Two problems: a. xtime is limited to HZ resolution which is insufficient for more advanced packet schedulers and rtt estimation. b. unlocked access to xtime is unsafe because it is not atomic! ATM is busted if it does this. gettimeofday on 2.6 should be cheap for many systems because of the lockless seqlock. Unfortunately, some architectures (not sure about ia64) have problems with TSC synchronization which make life messy. It might be possible to introduce a per-cpu monotonic clock that is lockless for use in network code, but that is a moderately painful undertaking which is beyond the scope of getting 2.6.0 out. From mitch@sfgoth.com Thu Oct 2 13:37:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 13:38:20 -0700 (PDT) Received: from gaz.sfgoth.com ([63.205.85.133]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92Kbj25018608 for ; Thu, 2 Oct 2003 13:37:45 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.9p1/8.12.9) with ESMTP id h92Kka16032033; Thu, 2 Oct 2003 13:46:36 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.9p1/8.12.6/Submit) id h92Kkawr032032; Thu, 2 Oct 2003 13:46:36 -0700 (PDT) (envelope-from mitch) Date: Thu, 2 Oct 2003 13:46:36 -0700 From: Mitchell Blank Jr To: Stephen Hemminger Cc: Steve Modica , netdev@oss.sgi.com Subject: Re: do_gettimeofday Message-ID: <20031002204636.GB30579@gaz.sfgoth.com> References: <3F7C6F3B.6070502@sgi.com> <20031002125625.72b8c0a7.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031002125625.72b8c0a7.shemminger@osdl.org> User-Agent: Mutt/1.4.1i X-archive-position: 461 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev Stephen Hemminger wrote: > Two problems: > a. xtime is limited to HZ resolution which is insufficient for more advanced > packet schedulers and rtt estimation. > b. unlocked access to xtime is unsafe because it is not atomic! > > ATM is busted if it does this. It got fixed in 2.5 (when skb->stamp got changed to nanosecond resolution so it broke the compile to do it the old way) You can use LXR to see all of the xtime users as of 2.6.0-test2: http://lxr.linux.no/ident?v=2.6.0-test2&i=xtime The reason that ATM _had_ been using xtime was not for performance. When the ATM code was originally written (during the 1.X kernels) all network drivers used xtime directly. At some point the network drivers were mass-updated to use do_gettimeofday() but ATM had not been merged into the main tree yet so it missed the conversion. -Mitch From laforge@netfilter.org Thu Oct 2 13:59:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 14:00:30 -0700 (PDT) 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 h92Kxs25020235 for ; Thu, 2 Oct 2003 13:59:55 -0700 Received: from uucp by coruscant.gnumonks.org with local-bsmtp (Exim 4.22) id 1A3vP0-0002YT-Nu for netdev@oss.sgi.com; Mon, 29 Sep 2003 12:37:14 +0200 Received: from laforge by obroa-skai.gnumonks.org with local (Exim 3.36 #1) id 1A3tcE-0000JZ-00; Mon, 29 Sep 2003 10:42:46 +0200 Date: Mon, 29 Sep 2003 10:42:46 +0200 From: Harald Welte To: Pekka Savola Cc: Andras Kis-Szabo , Yasuyuki Kozakai , Netfilter Devel , Netdev , usagi-core@linux-ipv6.org Subject: Re: [Patch]: IPv6 Connection Tracking Message-ID: <20030929084246.GE654@obroa-skai.de.gnumonks.org> Mail-Followup-To: Harald Welte , Pekka Savola , Andras Kis-Szabo , Yasuyuki Kozakai , Netfilter Devel , Netdev , usagi-core@linux-ipv6.org References: <1064515680.995.41.camel@localhost> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SFyWQ0h3ruR435lw" Content-Disposition: inline In-Reply-To: X-Operating-System: Linux obroa-skai.de.gnumonks.org 2.4.23-pre5 X-Date: Today is Boomtime, the 53rd day of Bureaucracy in the YOLD 3169 User-Agent: Mutt/1.5.4i X-archive-position: 462 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev --SFyWQ0h3ruR435lw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 25, 2003 at 09:57:47PM +0300, Pekka Savola wrote: > First, a meta-comment: >=20 > What I fear is that in the end, nothing gets done because having the goal > set to perfection. If there is no energy to drive through the > L3-independent connecting tracking, the end result is that the user > does not have this feature=20 well, that's the reason why I'd like to see it in=20 > (remember ip6tables REJECT target? That must have been sitting in > netfilter for some 2+ years, and not having been integrated in the > mainline kernel and the users still do not have the feature!). Mh, nobody has bugged me about that in all those 2 years. At least I don't remember somebody asking me for kernel inclusion...=20 Since ipv4 REJECT has now changed > So, my personal take is: > - if a L3-independent conn tracking can be done *quickly*, fine, I've started to write a small paper about the envisioned desgign. It doesn't look all that complicated, if somebody can concentrate on this job. I personally (as indicated before) do not have the time to work on that issue. But I'm happy to give advise. > - if not, just merge the current one, start working on L3 independent=20 > conn tracking, and add it when available. I understand your point. However, I fear to be the one responsible of keeping ip6_conntrack in sync with ip_conntrack. If there is a volunteer (maybe Yasuyuki?) who would really commit himself to look at which changes go into ip_conntack, and sending me patches to sync ip6_conntrack, I'd be more inclined to submit ip6_conntrack to the mainline kernel. =20 > .. but I'm not the one who's answering the support emails, so in all=20 > fairness, I should be silent now.. ;) --=20 - Harald Welte http://www.netfilter.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 "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --SFyWQ0h3ruR435lw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/d/CGXaXGVTD0i/8RAuZsAJ9+gG8tUawwy3u+4BTicBOkZdrZrgCfd7g2 k4SWLLMxIJc463EcS4hSfBM= =SWcD -----END PGP SIGNATURE----- --SFyWQ0h3ruR435lw-- From tytso@thunk.org Thu Oct 2 15:08:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 15:08:37 -0700 (PDT) Received: from thunker.thunk.org (thunk.org [140.239.227.29]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92M8125024011 for ; Thu, 2 Oct 2003 15:08:02 -0700 Received: from h-68-164-15-244.chcgilgm.dynamic.covad.net ([68.164.15.244] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1A4LPM-0007IY-00; Tue, 30 Sep 2003 10:23:20 -0400 Received: from tytso by thunk.org with local (Exim 4.22) id 1A4LNy-0007Ql-MZ; Tue, 30 Sep 2003 10:21:54 -0400 Date: Tue, 30 Sep 2003 10:21:54 -0400 From: "Theodore Ts'o" To: David Woodhouse Cc: "David S. Miller" , bunk@fs.tum.de, acme@conectiva.com.br, netdev@oss.sgi.com, pekkas@netcore.fi, lksctp-developers@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: RFC: [2.6 patch] disallow modular IPv6 Message-ID: <20030930142154.GA28501@thunk.org> Mail-Followup-To: Theodore Ts'o , David Woodhouse , "David S. Miller" , bunk@fs.tum.de, acme@conectiva.com.br, netdev@oss.sgi.com, pekkas@netcore.fi, lksctp-developers@lists.sourceforge.net, linux-kernel@vger.kernel.org References: <20030928225941.GW15338@fs.tum.de> <20030928231842.GE1039@conectiva.com.br> <20030928232403.GX15338@fs.tum.de> <20030929220916.19c9c90d.davem@redhat.com> <1064903562.6154.160.camel@imladris.demon.co.uk> <20030930000302.3e1bf8bb.davem@redhat.com> <1064907572.21551.31.camel@hades.cambridge.redhat.com> <20030930010855.095c2c35.davem@redhat.com> <1064910398.21551.41.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1064910398.21551.41.camel@hades.cambridge.redhat.com> User-Agent: Mutt/1.5.4i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-archive-position: 463 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tytso@mit.edu Precedence: bulk X-list: netdev On Tue, Sep 30, 2003 at 09:26:38AM +0100, David Woodhouse wrote: > > The suggestions I see do nothing to enhance the kernel tree as it currently > > stands. If you wish to prevent the kernel image from changing due to > > out-of-tree modules being built, fine, but don't impose this restriction > > upon in-kernel modules. > > It's a matter of taste. As I said, it's your right to disagree. > > Some time during 2.7 I'm sure one of the many people who agree with > Adrian and myself will send patches to Linus and he'll get to arbitrate. FWIW, I agree with Dave. Most of the time, enabling a device driver won't cause the core kernel to change, sure. However, there will be cases (such as enabling wireless ethernet drivers as modules, for example) where in order to support those modules, some new core kernel infrastructure will need to be enabled. Now, there are a couple of ways ways you can handle this. One is that the core infrastructure could have its own CONFIG_infrastructure boolean, and if that symbol is 'no', then you won't be able to build those modules until you recompile the base kernel with CONFIG_infrastructure. Another is that you can make enabling any one of the device driver modules "automatically" enable inclusion of the base core infrastructure. It then all boils down to tradeoffs and aesthetics. By making CONFIG_infrastructure explicit, it makes it more clear what is going on --- but if it is defaulted on, or if you require that whatever is under the CONFIG_infrastructure ifdef is always compiled in, then that way leads to kernel boot. But if it is defaulted off, then the user will be forced to recompile the kernel anyway, before he/she can enable the kernel module in question. Including CONFIG_infrastructure explicitly also makes the kernel build process more complex, and can also make life more confusing to the user --- the question about whether or not you can build a particular device driver won't even appear until the user enables CONFIG_infrastructure, and the user may have a really hard time figuring out that CONFIG_infrastructure is the way to make a particular device driver appear. For that reason, I tend to prefer the approach of simply enabling a device driver, and then letting that force a change in the base kernel to include any necessary base infrastructure in the kernel if necessary. It's simpler from a configuration perspective. And if the user types "make modules" after making such a change, ideally the build system should warn the user that it will be necessary to rebuild the base kernel before it can build the module. - Ted From shemminger@osdl.org Thu Oct 2 15:21:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 15:21:59 -0700 (PDT) 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 h92MLQ25025901 for ; Thu, 2 Oct 2003 15:21:26 -0700 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 h92MKu122999; Thu, 2 Oct 2003 15:20:56 -0700 Date: Thu, 2 Oct 2003 15:20:31 -0700 From: Stephen Hemminger To: Jean Tourrilhes , "David S. Miller" Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (2/11) tekram dongle module conversion Message-Id: <20031002152031.779022e5.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 465 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 -Nru a/drivers/net/irda/tekram.c b/drivers/net/irda/tekram.c --- a/drivers/net/irda/tekram.c Thu Oct 2 15:10:26 2003 +++ b/drivers/net/irda/tekram.c Thu Oct 2 15:10:26 2003 @@ -44,12 +44,12 @@ #define TEKRAM_PW 0x10 /* Pulse select bit */ static struct dongle_reg dongle = { - Q_NULL, - IRDA_TEKRAM_DONGLE, - tekram_open, - tekram_close, - tekram_reset, - tekram_change_speed, + .type = IRDA_TEKRAM_DONGLE, + .open = tekram_open, + .close = tekram_close, + .reset = tekram_reset, + .change_speed = tekram_change_speed, + .owner = THIS_MODULE, }; int __init tekram_init(void) @@ -69,8 +69,6 @@ qos->baud_rate.bits &= IR_9600|IR_19200|IR_38400|IR_57600|IR_115200; qos->min_turn_time.bits = 0x01; /* Needs at least 10 ms */ irda_qos_bits_to_value(qos); - - MOD_INC_USE_COUNT; } static void tekram_close(dongle_t *self) @@ -84,8 +82,6 @@ irda_task_delete(self->reset_task); if (self->speed_task) irda_task_delete(self->speed_task); - - MOD_DEC_USE_COUNT; } /* From shemminger@osdl.org Thu Oct 2 15:21:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 15:21:57 -0700 (PDT) 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 h92MLO25025900 for ; Thu, 2 Oct 2003 15:21:24 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h92MKr122995; Thu, 2 Oct 2003 15:20:53 -0700 Date: Thu, 2 Oct 2003 15:20:26 -0700 From: Stephen Hemminger To: Jean Tourrilhes , "David S. Miller" Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (1/11) Irda dongle module owner support Message-Id: <20031002152026.4bfd2c67.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 464 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 IRDA dongle interface needed to be converted to have an owner field to avoid races on module unload. Eliminated the use of hashbin locking because the dongle control code needed to do it's own locking to avoid races. This also closed the race between find and insert. The find/insert hashbin race may be a general problem with all the IRDA hashbin stuff. IMHO the hashbin stuff should be replaced, it is full of dead incomplete code and done better by the list macros. diff -Nru a/include/net/irda/irda_device.h b/include/net/irda/irda_device.h --- a/include/net/irda/irda_device.h Thu Oct 2 14:51:18 2003 +++ b/include/net/irda/irda_device.h Thu Oct 2 14:51:18 2003 @@ -128,6 +128,7 @@ void (*close)(dongle_t *dongle); int (*reset)(struct irda_task *task); int (*change_speed)(struct irda_task *task); + struct module *owner; }; /* diff -Nru a/net/irda/irda_device.c b/net/irda/irda_device.c --- a/net/irda/irda_device.c Thu Oct 2 14:51:18 2003 +++ b/net/irda/irda_device.c Thu Oct 2 14:51:18 2003 @@ -58,6 +58,7 @@ static void __irda_task_delete(struct irda_task *task); static hashbin_t *dongles = NULL; +static spinlock_t dongle_lock = SPIN_LOCK_UNLOCKED; static hashbin_t *tasks = NULL; const char *infrared_mode[] = { @@ -85,7 +86,7 @@ int __init irda_device_init( void) { - dongles = hashbin_new(HB_LOCK); + dongles = hashbin_new(HB_NOLOCK); if (dongles == NULL) { printk(KERN_WARNING "IrDA: Can't allocate dongles hashbin!\n"); return -ENOMEM; @@ -424,25 +425,35 @@ dongle_t *irda_device_dongle_init(struct net_device *dev, int type) { struct dongle_reg *reg; - dongle_t *dongle; + dongle_t *dongle = NULL; ASSERT(dev != NULL, return NULL;); + ASSERT(!in_interrupt(), return NULL;); + + spin_lock(&dongle_lock); + reg = hashbin_find(dongles, type, NULL); #ifdef CONFIG_KMOD - ASSERT(!in_interrupt(), return NULL;); /* Try to load the module needed */ - request_module("irda-dongle-%d", type); + if (!reg && capable(CAP_SYS_MODULE)) { + spin_unlock(&dongle_lock); + + request_module("irda-dongle-%d", type); + + spin_lock(&dongle_lock); + reg = hashbin_find(dongles, type, NULL); + } #endif - if (!(reg = hashbin_lock_find(dongles, type, NULL))) { - ERROR("IrDA: Unable to find requested dongle\n"); - return NULL; + if (!reg || !try_module_get(reg->owner) ) { + ERROR("IrDA: Unable to find requested dongle type %x\n", type); + goto out; } /* Allocate dongle info for this instance */ dongle = kmalloc(sizeof(dongle_t), GFP_KERNEL); if (!dongle) - return NULL; + goto out; memset(dongle, 0, sizeof(dongle_t)); @@ -450,6 +461,8 @@ dongle->issue = reg; dongle->dev = dev; + out: + spin_unlock(&dongle_lock); return dongle; } @@ -461,7 +474,7 @@ ASSERT(dongle != NULL, return -1;); dongle->issue->close(dongle); - + module_put(dongle->issue->owner); kfree(dongle); return 0; @@ -472,14 +485,16 @@ */ int irda_device_register_dongle(struct dongle_reg *new) { + spin_lock(&dongle_lock); /* Check if this dongle has been registered before */ - if (hashbin_lock_find(dongles, new->type, NULL)) { - MESSAGE("%s: Dongle already registered\n", __FUNCTION__); - return 0; - } - - /* Insert IrDA dongle into hashbin */ - hashbin_insert(dongles, (irda_queue_t *) new, new->type, NULL); + if (hashbin_find(dongles, new->type, NULL)) { + MESSAGE("%s: Dongle type %x already registered\n", + __FUNCTION__, new->type); + } else { + /* Insert IrDA dongle into hashbin */ + hashbin_insert(dongles, (irda_queue_t *) new, new->type, NULL); + } + spin_unlock(&dongle_lock); return 0; } @@ -494,11 +509,11 @@ { struct dongle *node; + spin_lock(&dongle_lock); node = hashbin_remove(dongles, dongle->type, NULL); - if (!node) { + if (!node) ERROR("%s: dongle not found!\n", __FUNCTION__); - return; - } + spin_unlock(&dongle_lock); } /* From shemminger@osdl.org Thu Oct 2 15:29:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 15:29:54 -0700 (PDT) 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 h92MTM25026618 for ; Thu, 2 Oct 2003 15:29:22 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h92MSq124964; Thu, 2 Oct 2003 15:28:52 -0700 Date: Thu, 2 Oct 2003 15:27:41 -0700 From: Stephen Hemminger To: Jean Tourrilhes , "David S. Miller" Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (3/11) act200l dongle -- module owner Message-Id: <20031002152741.656610bd.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 466 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 Convert act200l dongle to use module owner. diff -Nru a/drivers/net/irda/act200l.c b/drivers/net/irda/act200l.c --- a/drivers/net/irda/act200l.c Thu Oct 2 15:10:29 2003 +++ b/drivers/net/irda/act200l.c Thu Oct 2 15:10:29 2003 @@ -84,12 +84,12 @@ #define ACT200L_OSCL 0x04 /* oscillator in low power, medium accuracy mode */ static struct dongle_reg dongle = { - Q_NULL, - IRDA_ACT200L_DONGLE, - act200l_open, - act200l_close, - act200l_reset, - act200l_change_speed, + .type = IRDA_ACT200L_DONGLE, + .open = act200l_open, + .close = act200l_close, + .reset = act200l_reset, + .change_speed = act200l_change_speed, + .owner = THIS_MODULE, }; int __init act200l_init(void) @@ -112,8 +112,6 @@ /* Set the speeds we can accept */ qos->baud_rate.bits &= IR_9600|IR_19200|IR_38400|IR_57600|IR_115200; qos->min_turn_time.bits = 0x03; - - MOD_INC_USE_COUNT; } static void act200l_close(dongle_t *self) @@ -122,8 +120,6 @@ /* Power off the dongle */ self->set_dtr_rts(self->dev, FALSE, FALSE); - - MOD_DEC_USE_COUNT; } /* From shemminger@osdl.org Thu Oct 2 15:29:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 15:30:05 -0700 (PDT) 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 h92MTW25026628 for ; Thu, 2 Oct 2003 15:29:32 -0700 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 h92MSr124976; Thu, 2 Oct 2003 15:28:53 -0700 Date: Thu, 2 Oct 2003 15:25:57 -0700 From: Stephen Hemminger To: Jean Tourrilhes , "David S. Miller" Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (6/11) esi dongle - module owner Message-Id: <20031002152557.59dec7ce.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 468 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 Convert ESI dongle to use module owner diff -Nru a/drivers/net/irda/esi.c b/drivers/net/irda/esi.c --- a/drivers/net/irda/esi.c Thu Oct 2 15:10:36 2003 +++ b/drivers/net/irda/esi.c Thu Oct 2 15:10:36 2003 @@ -44,12 +44,12 @@ static int esi_reset(struct irda_task *task); static struct dongle_reg dongle = { - Q_NULL, - IRDA_ESI_DONGLE, - esi_open, - esi_close, - esi_reset, - esi_change_speed, + .type = IRDA_ESI_DONGLE, + .open = esi_open, + .close = esi_close, + .reset = esi_reset, + .change_speed = esi_change_speed, + .owner = THIS_MODULE, }; int __init esi_init(void) @@ -66,16 +66,12 @@ { qos->baud_rate.bits &= IR_9600|IR_19200|IR_115200; qos->min_turn_time.bits = 0x01; /* Needs at least 10 ms */ - - MOD_INC_USE_COUNT; } static void esi_close(dongle_t *dongle) { /* Power off dongle */ dongle->set_dtr_rts(dongle->dev, FALSE, FALSE); - - MOD_DEC_USE_COUNT; } /* From shemminger@osdl.org Thu Oct 2 15:29:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 15:30:01 -0700 (PDT) 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 h92MTS25026625 for ; Thu, 2 Oct 2003 15:29:28 -0700 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 h92MSr124972; Thu, 2 Oct 2003 15:28:53 -0700 Date: Thu, 2 Oct 2003 15:28:12 -0700 From: Stephen Hemminger To: Jean Tourrilhes , "David S. Miller" Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (5/11) ep7211_ir dongle -- module owner Message-Id: <20031002152812.2bddb04d.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 467 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 Convert ep7211_ir dongle to use module owner. diff -Nru a/drivers/net/irda/ep7211_ir.c b/drivers/net/irda/ep7211_ir.c --- a/drivers/net/irda/ep7211_ir.c Thu Oct 2 15:10:34 2003 +++ b/drivers/net/irda/ep7211_ir.c Thu Oct 2 15:10:34 2003 @@ -24,12 +24,12 @@ static int ep7211_ir_reset(struct irda_task *task); static struct dongle_reg dongle = { - Q_NULL, - IRDA_EP7211_IR, - ep7211_ir_open, - ep7211_ir_close, - ep7211_ir_reset, - ep7211_ir_change_speed, + .type = IRDA_EP7211_IR, + .open = ep7211_ir_open, + .close = ep7211_ir_close, + .reset = ep7211_ir_reset, + .change_speed = ep7211_ir_change_speed, + .owner = THIS_MODULE, }; static void ep7211_ir_open(dongle_t *self, struct qos_info *qos) @@ -47,8 +47,6 @@ UART (interrupt #14). */ restore_flags(flags); - - MOD_INC_USE_COUNT; } static void ep7211_ir_close(dongle_t *self) @@ -66,8 +64,6 @@ reset them back to their original state. */ restore_flags(flags); - - MOD_DEC_USE_COUNT; } /* From shemminger@osdl.org Thu Oct 2 15:29:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 15:30:19 -0700 (PDT) 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 h92MTk25026644 for ; Thu, 2 Oct 2003 15:29:46 -0700 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 h92MSr124968; Thu, 2 Oct 2003 15:28:53 -0700 Date: Thu, 2 Oct 2003 15:28:00 -0700 From: Stephen Hemminger To: Jean Tourrilhes , "David S. Miller" Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH} (4/11) actisys donge -- module owner Message-Id: <20031002152800.6bbbc0f6.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 469 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 Convert actisys to use owner field. diff -Nru a/drivers/net/irda/actisys.c b/drivers/net/irda/actisys.c --- a/drivers/net/irda/actisys.c Thu Oct 2 15:10:31 2003 +++ b/drivers/net/irda/actisys.c Thu Oct 2 15:10:31 2003 @@ -64,21 +64,21 @@ #define MAX_SPEEDS 5 static struct dongle_reg dongle = { - Q_NULL, - IRDA_ACTISYS_DONGLE, - actisys_open, - actisys_close, - actisys_reset, - actisys_change_speed, + .type = IRDA_ACTISYS_DONGLE, + .open = actisys_open, + .close = actisys_close, + .reset = actisys_reset, + .change_speed = actisys_change_speed, + .owner = THIS_MODULE, }; static struct dongle_reg dongle_plus = { - Q_NULL, - IRDA_ACTISYS_PLUS_DONGLE, - actisys_open, - actisys_close, - actisys_reset, - actisys_change_speed, + .type = IRDA_ACTISYS_PLUS_DONGLE, + .open = actisys_open, + .close = actisys_close, + .reset = actisys_reset, + .change_speed = actisys_change_speed, + .owner = THIS_MODULE, }; /* @@ -128,16 +128,12 @@ qos->baud_rate.bits &= ~IR_38400; qos->min_turn_time.bits = 0x7f; /* Needs 0.01 ms */ - - MOD_INC_USE_COUNT; } static void actisys_close(dongle_t *self) { /* Power off the dongle */ self->set_dtr_rts(self->dev, FALSE, FALSE); - - MOD_DEC_USE_COUNT; } /* From shemminger@osdl.org Thu Oct 2 15:30:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 15:30:43 -0700 (PDT) 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 h92MU525026696 for ; Thu, 2 Oct 2003 15:30:07 -0700 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 h92MSs124980; Thu, 2 Oct 2003 15:28:54 -0700 Date: Thu, 2 Oct 2003 15:27:01 -0700 From: Stephen Hemminger To: Jean Tourrilhes , "David S. Miller" Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (8/11) litelink dongle -- module owner Message-Id: <20031002152701.118303b1.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 470 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 Convert litelink dongle to use module owner diff -Nru a/drivers/net/irda/litelink.c b/drivers/net/irda/litelink.c --- a/drivers/net/irda/litelink.c Thu Oct 2 15:10:41 2003 +++ b/drivers/net/irda/litelink.c Thu Oct 2 15:10:41 2003 @@ -48,12 +48,12 @@ static __u32 baud_rates[] = { 115200, 57600, 38400, 19200, 9600 }; static struct dongle_reg dongle = { - Q_NULL, - IRDA_LITELINK_DONGLE, - litelink_open, - litelink_close, - litelink_reset, - litelink_change_speed, + .type = IRDA_LITELINK_DONGLE, + .open = litelink_open, + .close = litelink_close, + .reset = litelink_reset, + .change_speed = litelink_change_speed, + .owner = THIS_MODULE, }; int __init litelink_init(void) @@ -70,16 +70,12 @@ { qos->baud_rate.bits &= IR_9600|IR_19200|IR_38400|IR_57600|IR_115200; qos->min_turn_time.bits = 0x7f; /* Needs 0.01 ms */ - - MOD_INC_USE_COUNT; } static void litelink_close(dongle_t *self) { /* Power off dongle */ self->set_dtr_rts(self->dev, FALSE, FALSE); - - MOD_DEC_USE_COUNT; } /* From shemminger@osdl.org Thu Oct 2 15:33:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 15:33:41 -0700 (PDT) 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 h92MWl25028267 for ; Thu, 2 Oct 2003 15:33:08 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h92MWF125856; Thu, 2 Oct 2003 15:32:15 -0700 Date: Thu, 2 Oct 2003 15:31:48 -0700 From: Stephen Hemminger To: Jean Tourrilhes , "David S. Miller" Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (7/11) girbil dongle -- module owner Message-Id: <20031002153148.18da36da.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 471 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 Convert girbil dongle to use module owner instead of MOD_INC/DEC diff -Nru a/drivers/net/irda/girbil.c b/drivers/net/irda/girbil.c --- a/drivers/net/irda/girbil.c Thu Oct 2 15:10:39 2003 +++ b/drivers/net/irda/girbil.c Thu Oct 2 15:10:39 2003 @@ -63,12 +63,12 @@ #define GIRBIL_LOAD 0x51 /* Load the new baud rate value */ static struct dongle_reg dongle = { - Q_NULL, - IRDA_GIRBIL_DONGLE, - girbil_open, - girbil_close, - girbil_reset, - girbil_change_speed, + .type = IRDA_GIRBIL_DONGLE, + .open = girbil_open, + .close = girbil_close, + .reset = girbil_reset, + .change_speed = girbil_change_speed, + .owner = THIS_MODULE, }; int __init girbil_init(void) @@ -85,16 +85,12 @@ { qos->baud_rate.bits &= IR_9600|IR_19200|IR_38400|IR_57600|IR_115200; qos->min_turn_time.bits = 0x03; - - MOD_INC_USE_COUNT; } static void girbil_close(dongle_t *self) { /* Power off dongle */ self->set_dtr_rts(self->dev, FALSE, FALSE); - - MOD_DEC_USE_COUNT; } /* From shemminger@osdl.org Thu Oct 2 15:36:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 15:36:46 -0700 (PDT) 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 h92MaD25028674 for ; Thu, 2 Oct 2003 15:36:13 -0700 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 h92MZe127299; Thu, 2 Oct 2003 15:35:40 -0700 Date: Thu, 2 Oct 2003 15:35:15 -0700 From: Stephen Hemminger To: Jean Tourrilhes , "David S. Miller" Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (11/11) old_belkin dongle module conversion Message-Id: <20031002153515.7897b1ca.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 473 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 Change old_belkin dongle to new module owner support. diff -Nru a/drivers/net/irda/old_belkin.c b/drivers/net/irda/old_belkin.c --- a/drivers/net/irda/old_belkin.c Thu Oct 2 15:10:48 2003 +++ b/drivers/net/irda/old_belkin.c Thu Oct 2 15:10:48 2003 @@ -74,12 +74,12 @@ /* static __u32 baud_rates[] = { 9600 }; */ static struct dongle_reg dongle = { - Q_NULL, - IRDA_OLD_BELKIN_DONGLE, - old_belkin_open, - old_belkin_close, - old_belkin_reset, - old_belkin_change_speed, + .type = IRDA_OLD_BELKIN_DONGLE, + .open = old_belkin_open, + .close = old_belkin_close, + .reset = old_belkin_reset, + .change_speed = old_belkin_change_speed, + .owner = THIS_MODULE, }; int __init old_belkin_init(void) @@ -98,16 +98,12 @@ qos->baud_rate.bits &= IR_9600; /* Needs at least 10 ms (totally wild guess, can do probably better) */ qos->min_turn_time.bits = 0x01; - - MOD_INC_USE_COUNT; } static void old_belkin_close(dongle_t *self) { /* Power off dongle */ self->set_dtr_rts(self->dev, FALSE, FALSE); - - MOD_DEC_USE_COUNT; } /* From shemminger@osdl.org Thu Oct 2 15:36:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 15:36:43 -0700 (PDT) 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 h92MaA25028672 for ; Thu, 2 Oct 2003 15:36:10 -0700 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 h92MZd127281; Thu, 2 Oct 2003 15:35:39 -0700 Date: Thu, 2 Oct 2003 15:35:14 -0700 From: Stephen Hemminger To: Jean Tourrilhes , "David S. Miller" , irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (10/11) mcp2120 dongle -- module owner Message-Id: <20031002153514.14e5d917.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 472 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 Convert mcp2120 dongle to use module owner instead of MOD_INC/DEC diff -Nru a/drivers/net/irda/mcp2120.c b/drivers/net/irda/mcp2120.c --- a/drivers/net/irda/mcp2120.c Thu Oct 2 15:10:46 2003 +++ b/drivers/net/irda/mcp2120.c Thu Oct 2 15:10:46 2003 @@ -40,12 +40,12 @@ #define MCP2120_COMMIT 0x11 static struct dongle_reg dongle = { - Q_NULL, - IRDA_MCP2120_DONGLE, - mcp2120_open, - mcp2120_close, - mcp2120_reset, - mcp2120_change_speed, + .type = IRDA_MCP2120_DONGLE, + .open = mcp2120_open, + .close = mcp2120_close, + .reset = mcp2120_reset, + .change_speed = mcp2120_change_speed, + .owner = THIS_MODULE, }; int __init mcp2120_init(void) @@ -62,8 +62,6 @@ { qos->baud_rate.bits &= IR_9600|IR_19200|IR_38400|IR_57600|IR_115200; qos->min_turn_time.bits = 0x01; - - MOD_INC_USE_COUNT; } static void mcp2120_close(dongle_t *self) @@ -72,8 +70,6 @@ /* reset and inhibit mcp2120 */ self->set_dtr_rts(self->dev, TRUE, TRUE); //self->set_dtr_rts(self->dev, FALSE, FALSE); - - MOD_DEC_USE_COUNT; } /* From shemminger@osdl.org Thu Oct 2 15:36:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 15:36:51 -0700 (PDT) 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 h92MaI25028681 for ; Thu, 2 Oct 2003 15:36:18 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h92MZb127270; Thu, 2 Oct 2003 15:35:37 -0700 Date: Thu, 2 Oct 2003 15:35:10 -0700 From: Stephen Hemminger To: Jean Tourrilhes , "David S. Miller" Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (9/11) ma600 dongle -- module owner Message-Id: <20031002153510.6bdd33bc.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 474 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 Yet another conversion of dongle from MOD_INC/DEC to module owner field. diff -Nru a/drivers/net/irda/ma600.c b/drivers/net/irda/ma600.c --- a/drivers/net/irda/ma600.c Thu Oct 2 15:10:43 2003 +++ b/drivers/net/irda/ma600.c Thu Oct 2 15:10:43 2003 @@ -74,12 +74,12 @@ #define MA600_2400 0x08 static struct dongle_reg dongle = { - Q_NULL, - IRDA_MA600_DONGLE, - ma600_open, - ma600_close, - ma600_reset, - ma600_change_speed, + .type = IRDA_MA600_DONGLE, + .open = ma600_open, + .close = ma600_close, + .reset = ma600_reset, + .change_speed = ma600_change_speed, + .owner = THIS_MODULE, }; int __init ma600_init(void) @@ -115,8 +115,6 @@ self->set_dtr_rts(self->dev, TRUE, TRUE); // should wait 1 second - - MOD_INC_USE_COUNT; } static void ma600_close(dongle_t *self) @@ -125,8 +123,6 @@ /* Power off dongle */ self->set_dtr_rts(self->dev, FALSE, FALSE); - - MOD_DEC_USE_COUNT; } static __u8 get_control_byte(__u32 speed) From jt@bougret.hpl.hp.com Thu Oct 2 16:33:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 16:34:11 -0700 (PDT) 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 h92NXa25001786 for ; Thu, 2 Oct 2003 16:33:36 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id E9D771C026E8; Thu, 2 Oct 2003 16:33:35 -0700 (PDT) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_28810)/8.9.3 HPLabs Timeshare Server) with ESMTP id QAA00739; Thu, 2 Oct 2003 16:33:35 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1A5Cwx-00026j-00; Thu, 02 Oct 2003 16:33:35 -0700 Date: Thu, 2 Oct 2003 16:33:35 -0700 To: Stephen Hemminger Cc: "David S. Miller" , irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (1/11) Irda dongle module owner support Message-ID: <20031002233335.GA7945@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20031002152026.4bfd2c67.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031002152026.4bfd2c67.shemminger@osdl.org> 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: 475 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 Thu, Oct 02, 2003 at 03:20:26PM -0700, Stephen Hemminger wrote: > > IRDA dongle interface needed to be converted to have an owner field > to avoid races on module unload. Yep, this code was broken. At this point, we were supposed to use the new dongle stuff of Martin, wich I think is correct, but it didn't happened. > Eliminated the use of hashbin locking because the dongle control > code needed to do it's own locking to avoid races. This also closed > the race between find and insert. Yep, that's the right approach. > The find/insert hashbin race may be a general problem with all the IRDA > hashbin stuff. This is clearly commented in the hashbin code (big block of comments). Note that this problem is not a problem of hashbin themselves, because there is only so much you can do there, but more about how you use hashbins. This is why over the last year a lot of critical IrDA code has migrated to HB_NOLOCK or/and use external locking, and therefore the situation is not as bad as it looks. Do a "grep hb_spinlock *" to confirm this (or check my web page) ;-) For the reason mentionned above, the dongle code and the task code were not upgraded. > IMHO the hashbin stuff should be replaced, it is full > of dead incomplete code and done better by the list macros. I somehow agree with that (check my comments on hashbin.c). However, as the majority of locking issues have been addressed during 2.5.X, it's not as critical, and as long as it works... > +static spinlock_t dongle_lock = SPIN_LOCK_UNLOCKED; The usual IrDA convention is to reuse &dongle->hb_spinlock rather than adding a new variable. Less bloat. > + spin_lock(&dongle_lock); I wonder if you need to lock BH as well. I'm not sure if all the dongles call are guaranteed to come from user space. You don't want to introduce nasty deadlocks ;-) > - ASSERT(!in_interrupt(), return NULL;); Hum... My recollections is that calling request_module with interrupt disable was guaranteed to crash. But that was with the "old" module code. I would prefer if you leave this stuff in, it helps debugging. Have fun... Jean From sri@us.ibm.com Thu Oct 2 16:46:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 16:46:53 -0700 (PDT) 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 h92NkE25002743 for ; Thu, 2 Oct 2003 16:46:21 -0700 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 h92Nk8E6372324; Thu, 2 Oct 2003 19:46:08 -0400 Received: from w-sridhar.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 h92Nk77C120164; Thu, 2 Oct 2003 17:46:07 -0600 Date: Thu, 2 Oct 2003 16:46:06 -0700 (PDT) From: Sridhar Samudrala X-X-Sender: sridhar@localhost.localdomain To: davem@redhat.com cc: netdev@oss.sgi.com Subject: [BK PATCH] 2.6 SCTP updates. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 476 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Hi Dave, Please do a bk pull http://linux-lksctp.bkbits.net/lksctp-2.5 to get the following udpates to SCTP on top of linux 2.6.0-test6 The changesets include fixes for a couple of arch specific issues with ppc64 and parisc64, few ADDIP extension related patches and a bug fix. # This patch includes the following deltas: # ChangeSet 1.1375 -> 1.1377 # net/sctp/associola.c 1.59 -> 1.61 # net/sctp/sm_statefuns.c 1.63 -> 1.64 # net/sctp/endpointola.c 1.28 -> 1.29 # net/sctp/sm_make_chunk.c 1.61 -> 1.64 # include/net/sctp/sctp.h 1.50 -> 1.52 # net/sctp/sysctl.c 1.13 -> 1.14 # include/net/sctp/sm.h 1.29 -> 1.31 # include/linux/sctp.h 1.8 -> 1.9 # net/sctp/sm_sideeffect.c 1.48 -> 1.49 # net/sctp/bind_addr.c 1.21 -> 1.22 # include/net/sctp/command.h 1.14 -> 1.15 # include/net/sctp/structs.h 1.73 -> 1.75 # net/sctp/socket.c 1.96 -> 1.99 # # The following is the BitKeeper ChangeSet Log # #ChangeSet@1.1377, 2003-10-02 11:36:34-07:00, sri@us.ibm.com # [SCTP] Fix bugs in conversions between msecs and jiffies. # #ChangeSet@1.1376, 2003-09-29 12:04:57-07:00, sri@us.ibm.com # Merge us.ibm.com:/home/sridhar/BK/linux-2.6.0-test6 # into us.ibm.com:/home/sridhar/BK/lksctp-2.6.0-test6 # #ChangeSet@1.1217.15.5, 2003-09-29 10:23:40-07:00, sri@us.ibm.com # [SCTP] Convert tv_add from static inline to a macro to fix an obscure # assembler problem with parisc64. # #ChangeSet@1.1217.15.4, 2003-09-22 14:29:35-07:00, sri@us.ibm.com # [SCTP] ADDIP: Support for the creation of ASCONF_ACK chunk (Kevin). # #ChangeSet@1.1217.15.3, 2003-09-18 14:44:14-07:00, sri@us.ibm.com # [SCTP] ADDIP: Handle ERROR chunk in response to an ASCONF chunk. # # Disable sending any further ASCONF chunks and stop its T-4 timer if # the peer responds to an ASCONF with an ERROR chunk. # #ChangeSet@1.1217.15.2, 2003-09-18 14:39:59-07:00, sri@us.ibm.com # [SCTP] ADDIP: Support to send ASCONF chunk with ADD/DEL IP params. # #ChangeSet@1.1217.15.1, 2003-09-09 11:03:31-07:00, sri@us.ibm.com # [SCTP] PPC64 port: Don't overload the optval arg of ADDRS_NUM socket # options with different types for input and output. Instead use it only # as an input arg and return the no. of addresses in the return value. Thanks Sridhar From ja@ssi.bg Thu Oct 2 17:10:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 17:11:10 -0700 (PDT) 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 h930AU25003850 for ; Thu, 2 Oct 2003 17:10:35 -0700 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.6/8.11.6) with ESMTP id h9300R104299; Fri, 3 Oct 2003 03:00:28 +0300 Date: Fri, 3 Oct 2003 03:00:27 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: "David S. Miller" cc: netdev@oss.sgi.com Subject: tunnel xmit and h.raw Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 477 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 Hello, Is the following change needed? May be yes for all kernels where the nearest skb_shared checks are actual. # 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.1356 -> 1.1357 # net/ipv4/ip_gre.c 1.30 -> 1.31 # net/ipv6/sit.c 1.28 -> 1.29 # net/ipv4/ipip.c 1.32 -> 1.33 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/10/03 ja@ssi.bg 1.1357 # [IPV4/IPV6]: tunnel xmit must load skb->h.raw after all reallocations # -------------------------------------------- # diff -Nru a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c --- a/net/ipv4/ip_gre.c Fri Oct 3 02:43:29 2003 +++ b/net/ipv4/ip_gre.c Fri Oct 3 02:43:29 2003 @@ -803,8 +803,6 @@ tunnel->err_count = 0; } - skb->h.raw = skb->nh.raw; - max_headroom = LL_RESERVED_SPACE(tdev) + gre_hlen; if (skb_headroom(skb) < max_headroom || skb_cloned(skb) || skb_shared(skb)) { @@ -823,6 +821,7 @@ old_iph = skb->nh.iph; } + skb->h.raw = skb->nh.raw; skb->nh.raw = skb_push(skb, gre_hlen); memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt)); dst_release(skb->dst); diff -Nru a/net/ipv4/ipip.c b/net/ipv4/ipip.c --- a/net/ipv4/ipip.c Fri Oct 3 02:43:29 2003 +++ b/net/ipv4/ipip.c Fri Oct 3 02:43:29 2003 @@ -596,8 +596,6 @@ tunnel->err_count = 0; } - skb->h.raw = skb->nh.raw; - /* * Okay, now see if we can stuff it in the buffer as-is. */ @@ -619,6 +617,7 @@ old_iph = skb->nh.iph; } + skb->h.raw = skb->nh.raw; skb->nh.raw = skb_push(skb, sizeof(struct iphdr)); memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt)); dst_release(skb->dst); diff -Nru a/net/ipv6/sit.c b/net/ipv6/sit.c --- a/net/ipv6/sit.c Fri Oct 3 02:43:29 2003 +++ b/net/ipv6/sit.c Fri Oct 3 02:43:29 2003 @@ -530,8 +530,6 @@ tunnel->err_count = 0; } - skb->h.raw = skb->nh.raw; - /* * Okay, now see if we can stuff it in the buffer as-is. */ @@ -553,6 +551,7 @@ iph6 = skb->nh.ipv6h; } + skb->h.raw = skb->nh.raw; skb->nh.raw = skb_push(skb, sizeof(struct iphdr)); memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt)); dst_release(skb->dst); Regards -- Julian Anastasov From scott.feldman@intel.com Thu Oct 2 17:38:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 17:39:11 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h930ca25004549 for ; Thu, 2 Oct 2003 17:38:37 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.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 h930cnY2007397 for ; Fri, 3 Oct 2003 00:38:49 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.fm.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 h930UON17236 for ; Fri, 3 Oct 2003 00:30:24 GMT Received: from [134.134.3.171] ([134.134.3.171]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003100217382822489 ; Thu, 02 Oct 2003 17:38:28 -0700 Date: Thu, 2 Oct 2003 18:06:27 -0700 (PDT) From: "Feldman, Scott" X-X-Sender: scott.feldman@localhost.localdomain Reply-To: "Feldman, Scott" To: Jeff Garzik cc: netdev@oss.sgi.com, "Feldman, Scott" Subject: [e1000 2.6] hang on ZEROCOPY/TSO when hitting no-Tx-resources condition Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 478 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev * Critical bug fix: under heavy Tx stress using ZEROCOPY or TSO, if we ran out of Tx descriptors, we didn't calculate for the context descritor used as the first of the ZEROCOPY/TSO send, nor do we clean up the context desriptor bits in the case where the send isn't going to fit, where we need to undo the mappings. This bug was introduced with the 5.2.16 patch set which included a workaround for a hang on 82544 over PCI-X. This workaround cause the check for no-Tx- rosource logic to change, and this bug slipped in. ------------ diff -Naurp net-drivers-2.5/drivers/net/e1000/e1000_main.c net-drivers-2.5/drivers/net/e1000.mod/e1000_main.c --- net-drivers-2.5/drivers/net/e1000/e1000_main.c 2003-10-02 17:34:04.000000000 -0700 +++ net-drivers-2.5/drivers/net/e1000.mod/e1000_main.c 2003-10-02 17:38:35.000000000 -0700 @@ -30,7 +30,7 @@ /* Change Log * - * 5.2.18 9/13/03 + * 5.2.20 9/30/03 * o Bug fix: SERDES devices might be connected to a back-plane * switch that doesn't support auto-neg, so add the capability * to force 1000/Full. @@ -39,6 +39,9 @@ * Jumbo Frames or with the reduced FIFO in 82547. * o Better propagation of error codes. [Janice Girouard * (janiceg@us.ibm.com)]. + * o Bug fix: hang under heavy Tx stress when running out of Tx + * descriptors; wasn't clearing context descriptor when backing + * out of send because of no-resource condition. * * 5.2.16 8/8/03 * o Added support for new controllers: 82545GM, 82546GB, 82541/7_B1 @@ -61,7 +64,7 @@ char e1000_driver_name[] = "e1000"; char e1000_driver_string[] = "Intel(R) PRO/1000 Network Driver"; -char e1000_driver_version[] = "5.2.19-k1"; +char e1000_driver_version[] = "5.2.20-k1"; char e1000_copyright[] = "Copyright (c) 1999-2003 Intel Corporation."; /* e1000_pci_tbl - PCI Device ID Table @@ -1501,6 +1504,7 @@ e1000_tx_map(struct e1000_adapter *adapt unsigned int first) { struct e1000_desc_ring *tx_ring = &adapter->tx_ring; + struct e1000_tx_desc *tx_desc; struct e1000_buffer *buffer_info; unsigned int len = skb->len, max_per_txd = E1000_MAX_DATA_PER_TXD; unsigned int offset = 0, size, count = 0, i; @@ -1596,17 +1600,29 @@ e1000_tx_map(struct e1000_adapter *adapt } } - if(E1000_DESC_UNUSED(&adapter->tx_ring) < count) { + if(E1000_DESC_UNUSED(&adapter->tx_ring) < count + 2) { /* There aren't enough descriptors available to queue up - * this send, so undo the mapping and abort the send. - * We could have done the check before we mapped the skb, - * but because of all the workarounds (above), it's too - * difficult to predict how many we're going to need.*/ - i = first; + * this send (need: count + 1 context desc + 1 desc gap + * to keep tail from touching head), so undo the mapping + * and abort the send. We could have done the check before + * we mapped the skb, but because of all the workarounds + * (above), it's too difficult to predict how many we're + * going to need.*/ + i = adapter->tx_ring.next_to_use; + + if(i == first) { + /* Cleanup after e1000_tx_[csum|tso] scribbling + * on descriptors. */ + tx_desc = E1000_TX_DESC(*tx_ring, first); + tx_desc->buffer_addr = 0; + tx_desc->lower.data = 0; + tx_desc->upper.data = 0; + } while(count--) { buffer_info = &tx_ring->buffer_info[i]; + if(buffer_info->dma) { pci_unmap_page(adapter->pdev, buffer_info->dma, @@ -1614,9 +1630,12 @@ e1000_tx_map(struct e1000_adapter *adapt PCI_DMA_TODEVICE); buffer_info->dma = 0; } + if(++i == tx_ring->count) i = 0; } + adapter->tx_ring.next_to_use = first; + return 0; } From scott.feldman@intel.com Thu Oct 2 17:54:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 17:55:15 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h930sf25005036 for ; Thu, 2 Oct 2003 17:54:41 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.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 h930ssY2025871 for ; Fri, 3 Oct 2003 00:54:54 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.fm.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 h930kTS25810 for ; Fri, 3 Oct 2003 00:46:29 GMT Received: from [134.134.3.171] ([134.134.3.171]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003100217543423606 ; Thu, 02 Oct 2003 17:54:34 -0700 Date: Thu, 2 Oct 2003 18:22:33 -0700 (PDT) From: "Feldman, Scott" X-X-Sender: scott.feldman@localhost.localdomain Reply-To: "Feldman, Scott" To: Jeff Garzik cc: netdev@oss.sgi.com, "Feldman, Scott" Subject: [e1000 2.4] hang on ZEROCOPY/TSO when hitting no-Tx-resources condition Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 479 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev * Critical bug fix: under heavy Tx stress using ZEROCOPY or TSO, if we run out of Tx descriptors, we don't calculate for the context descriptor used as the first of the ZEROCOPY/TSO send, nor do we clean up the context descriptor bits in the case where the send isn't going to fit and we need to undo the mappings. This bug was introduced with the 5.2.16 patch set which included a workaround for a hang on 82544 over PCI-X. This workaround caused the check for no-Tx- resource logic to change, and this bug slipped in. ------------- diff -Naurp net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.mod/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2003-10-02 18:08:45.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.mod/e1000_main.c 2003-10-02 18:12:48.000000000 -0700 @@ -59,7 +59,7 @@ char e1000_driver_name[] = "e1000"; char e1000_driver_string[] = "Intel(R) PRO/1000 Network Driver"; -char e1000_driver_version[] = "5.2.16-k1"; +char e1000_driver_version[] = "5.2.16-k2"; char e1000_copyright[] = "Copyright (c) 1999-2003 Intel Corporation."; /* e1000_pci_tbl - PCI Device ID Table @@ -1532,6 +1532,7 @@ e1000_tx_map(struct e1000_adapter *adapt unsigned int first) { struct e1000_desc_ring *tx_ring = &adapter->tx_ring; + struct e1000_tx_desc *tx_desc; struct e1000_buffer *buffer_info; unsigned int len = skb->len, max_per_txd = E1000_MAX_DATA_PER_TXD; unsigned int offset = 0, size, count = 0, i; @@ -1622,17 +1623,29 @@ e1000_tx_map(struct e1000_adapter *adapt } } - if(E1000_DESC_UNUSED(&adapter->tx_ring) < count) { + if(E1000_DESC_UNUSED(&adapter->tx_ring) < count + 2) { /* There aren't enough descriptors available to queue up - * this send, so undo the mapping and abort the send. - * We could have done the check before we mapped the skb, - * but because of all the workarounds (above), it's too - * difficult to predict how many we're going to need.*/ - i = first; + * this send (need: count + 1 context desc + 1 desc gap + * to keep tail from touching head), so undo the mapping + * and abort the send. We could have done the check before + * we mapped the skb, but because of all the workarounds + * (above), it's too difficult to predict how many we're + * going to need.*/ + i = adapter->tx_ring.next_to_use; + + if(i == first) { + /* Cleanup after e1000_tx_[csum|tso] scribbling + * on descriptors. */ + tx_desc = E1000_TX_DESC(*tx_ring, first); + tx_desc->buffer_addr = 0; + tx_desc->lower.data = 0; + tx_desc->upper.data = 0; + } while(count--) { buffer_info = &tx_ring->buffer_info[i]; + if(buffer_info->dma) { pci_unmap_page(adapter->pdev, buffer_info->dma, @@ -1640,9 +1653,12 @@ e1000_tx_map(struct e1000_adapter *adapt PCI_DMA_TODEVICE); buffer_info->dma = 0; } + if(++i == tx_ring->count) i = 0; } + adapter->tx_ring.next_to_use = first; + return 0; } From oxymoron@waste.org Thu Oct 2 18:41:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 18:41:56 -0700 (PDT) Received: from waste.org (waste.org [209.173.204.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h931fI25005946 for ; Thu, 2 Oct 2003 18:41:19 -0700 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id h931f4RT024444; Thu, 2 Oct 2003 20:41:04 -0500 Received: (from oxymoron@localhost) by waste.org (8.12.3/8.12.3/Debian-6.6) id h931f4Ck024442; Thu, 2 Oct 2003 20:41:04 -0500 Date: Thu, 2 Oct 2003 20:41:04 -0500 From: Matt Mackall To: netdev@oss.sgi.com Cc: Andrew Morton , Jeff Garzik Subject: [RFC] [PATCH 1/3] netpoll api Message-ID: <20031003014104.GR1897@waste.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new X-archive-position: 480 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev This patch implements a new netpoll API, which allows sending and receiving packets in context where interrupts may be disabled. It provides a common API for implementing features like netconsole, netdump/LKCD, and kgdb-over-ethernet and manages to isolate them almost completely from the details of the network layer. The second patch is an example of implementing the poll_controller hook needed to get a card to work with netpoll. Numerous other examples are in -mm and recent Red Hat kernels. The final patch is a reimplementation of netconsole against the netpoll api. 8< This patch provides interface for polling NICs with interrupts disabled, for both send and receive. It also provides an option parser for configuring network parameters for subsystems that use the polling interface. This functionality should be common between netconsole, netdump, kgdb-over-ethernet, etc. arch/i386/kernel/irq.c | 0 ml-mpm/include/linux/netdevice.h | 16 ml-mpm/include/linux/netpoll.h | 38 ++ ml-mpm/net/Kconfig | 11 ml-mpm/net/core/Makefile | 1 ml-mpm/net/core/dev.c | 15 ml-mpm/net/core/netpoll.c | 636 +++++++++++++++++++++++++++++++++++++++ 7 files changed, 717 insertions(+) diff -puN /dev/null net/core/netpoll.c --- /dev/null 2003-09-12 12:14:37.000000000 -0500 +++ ml-mpm/net/core/netpoll.c 2003-10-02 16:48:38.000000000 -0500 @@ -0,0 +1,636 @@ +/* + * Common framework for low-level network console, dump, and debugger code + * + * Sep 8 2003 Matt Mackall + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* + * We maintain a small pool of fully-sized skbs, to make sure the + * message gets out even in extreme OOM situations. + */ + +#define MAX_SKBS 32 +#define MAX_UDP_CHUNK 1460 + +static spinlock_t skb_list_lock = SPIN_LOCK_UNLOCKED; +static int nr_skbs; +static struct sk_buff *skbs; + +static spinlock_t rx_list_lock = SPIN_LOCK_UNLOCKED; +static LIST_HEAD(rx_list); + +static int trapped; + +#define MAX_SKB_SIZE \ + (MAX_UDP_CHUNK + sizeof(struct udphdr) + \ + sizeof(struct iphdr) + sizeof(struct ethhdr)) + +static int checksum_udp(struct sk_buff *skb, struct udphdr *uh, + unsigned short ulen, u32 saddr, u32 daddr) +{ + if (uh->check == 0) + return 0; + + if (skb->ip_summed == CHECKSUM_HW) + return csum_tcpudp_magic( + saddr, daddr, ulen, IPPROTO_UDP, skb->csum); + + skb->csum = csum_tcpudp_nofold(saddr, daddr, ulen, IPPROTO_UDP, 0); + + return csum_fold(skb_checksum(skb, 0, skb->len, skb->csum)); +} + +void netpoll_poll(struct netpoll *np) +{ + int budget = 1; + + if(!np->dev || !netif_running(np->dev) || !np->dev->poll_controller) + return; + + /* Process pending work on NIC */ + np->dev->poll_controller(np->dev); + + /* If scheduling is stopped, tickle NAPI bits */ + if(trapped && np->dev->poll && + test_bit(__LINK_STATE_RX_SCHED, &np->dev->state)) + np->dev->poll(np->dev, &budget); +} + +static void refill_skbs(void) +{ + struct sk_buff *skb; + unsigned long flags; + + spin_lock_irqsave(&skb_list_lock, flags); + while (nr_skbs < MAX_SKBS) { + skb = alloc_skb(MAX_SKB_SIZE, GFP_ATOMIC); + if (!skb) + break; + + skb->next = skbs; + skbs = skb; + nr_skbs++; + } + spin_unlock_irqrestore(&skb_list_lock, flags); +} + +static void zap_completion_queue(void) +{ + unsigned long flags; + struct softnet_data *sd = &get_cpu_var(softnet_data); + + if (sd->completion_queue) { + struct sk_buff *clist; + + local_irq_save(flags); + clist = sd->completion_queue; + sd->completion_queue = NULL; + local_irq_restore(flags); + + while (clist != NULL) { + struct sk_buff *skb = clist; + clist = clist->next; + __kfree_skb(skb); + } + } + + put_cpu_var(softnet_data); +} + +static struct sk_buff * find_skb(struct netpoll *np, int len, int reserve) +{ + int once = 1, count = 0; + unsigned long flags; + struct sk_buff *skb = NULL; + +repeat: + zap_completion_queue(); + if (nr_skbs < MAX_SKBS) + refill_skbs(); + + skb = alloc_skb(len, GFP_ATOMIC); + + if (!skb) { + spin_lock_irqsave(&skb_list_lock, flags); + skb = skbs; + if (skb) + skbs = skb->next; + skb->next = NULL; + nr_skbs--; + spin_unlock_irqrestore(&skb_list_lock, flags); + } + + if(!skb) { + count++; + if (once && (count == 1000000)) { + printk("out of netpoll skbs!\n"); + once = 0; + } + netpoll_poll(np); + goto repeat; + } + + atomic_set(&skb->users, 1); + skb_reserve(skb, reserve); + return skb; +} + +void netpoll_send_skb(struct netpoll *np, struct sk_buff *skb) +{ + int status; + +repeat: + if(!np || !np->dev || !netif_running(np->dev)) { + __kfree_skb(skb); + return; + } + + spin_lock(&np->dev->xmit_lock); + np->dev->xmit_lock_owner = smp_processor_id(); + + if (netif_queue_stopped(np->dev)) { + np->dev->xmit_lock_owner = -1; + spin_unlock(&np->dev->xmit_lock); + + netpoll_poll(np); + zap_completion_queue(); + goto repeat; + } + + status = np->dev->hard_start_xmit(skb, np->dev); + np->dev->xmit_lock_owner = -1; + spin_unlock(&np->dev->xmit_lock); + + /* transmit busy */ + if(status) + goto repeat; +} + +void netpoll_send_udp(struct netpoll *np, const char *msg, int len) +{ + int total_len, eth_len, ip_len, udp_len; + struct sk_buff *skb; + struct udphdr *udph; + struct iphdr *iph; + struct ethhdr *eth; + + udp_len = len + sizeof(*udph); + ip_len = eth_len = udp_len + sizeof(*iph); + total_len = eth_len + ETH_HLEN; + + skb = find_skb(np, total_len, total_len - len); + if (!skb) + return; + + memcpy(skb->data, msg, len); + skb->len += len; + + udph = (struct udphdr *) skb_push(skb, sizeof(*udph)); + udph->source = htons(np->local_port); + udph->dest = htons(np->remote_port); + udph->len = htons(udp_len); + udph->check = 0; + + iph = (struct iphdr *)skb_push(skb, sizeof(*iph)); + + iph->version = 4; + iph->ihl = 5; + iph->tos = 0; + iph->tot_len = htons(ip_len); + iph->id = 0; + iph->frag_off = 0; + iph->ttl = 64; + iph->protocol = IPPROTO_UDP; + iph->check = 0; + iph->saddr = htonl(np->local_ip); + iph->daddr = htonl(np->remote_ip); + iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl); + + eth = (struct ethhdr *) skb_push(skb, ETH_HLEN); + + eth->h_proto = htons(ETH_P_IP); + memcpy(eth->h_source, np->local_mac, 6); + memcpy(eth->h_dest, np->remote_mac, 6); + + netpoll_send_skb(np, skb); +} + +static void arp_reply(struct sk_buff *skb) +{ + struct in_device *in_dev = (struct in_device *) skb->dev->ip_ptr; + struct arphdr *arp; + unsigned char *arp_ptr, *sha, *tha; + int size, type = ARPOP_REPLY, ptype = ETH_P_ARP; + u32 sip, tip; + struct sk_buff *send_skb; + unsigned long flags; + struct list_head *p; + struct netpoll *np = 0; + + spin_lock_irqsave(&rx_list_lock, flags); + list_for_each(p, &rx_list) { + np = list_entry(p, struct netpoll, rx_list); + if ( np->dev == skb->dev ) + break; + np = 0; + } + spin_unlock_irqrestore(&rx_list_lock, flags); + + if (!np) return; + + /* No arp on this interface */ + if (!in_dev || skb->dev->flags & IFF_NOARP) + return; + + if (!pskb_may_pull(skb, (sizeof(struct arphdr) + + (2 * skb->dev->addr_len) + + (2 * sizeof(u32))))) + return; + + skb->h.raw = skb->nh.raw = skb->data; + arp = skb->nh.arph; + + if ((arp->ar_hrd != htons(ARPHRD_ETHER) && + arp->ar_hrd != htons(ARPHRD_IEEE802)) || + arp->ar_pro != htons(ETH_P_IP) || + arp->ar_op != htons(ARPOP_REQUEST)) + return; + + arp_ptr= (unsigned char *)(arp+1); + sha = arp_ptr; + arp_ptr += skb->dev->addr_len; + memcpy(&sip, arp_ptr, 4); + arp_ptr += 4; + tha = arp_ptr; + arp_ptr += skb->dev->addr_len; + memcpy(&tip, arp_ptr, 4); + + /* Should we ignore arp? */ + if (tip != in_dev->ifa_list->ifa_address || + LOOPBACK(tip) || MULTICAST(tip)) + return; + + + size = sizeof(struct arphdr) + 2 * (skb->dev->addr_len + 4); + send_skb = find_skb(np, size + LL_RESERVED_SPACE(np->dev), + LL_RESERVED_SPACE(np->dev)); + + if (!send_skb) + return; + + send_skb->nh.raw = send_skb->data; + arp = (struct arphdr *) skb_put(send_skb, size); + send_skb->dev = skb->dev; + send_skb->protocol = htons(ETH_P_ARP); + + /* Fill the device header for the ARP frame */ + + if (np->dev->hard_header && + np->dev->hard_header(send_skb, skb->dev, ptype, + np->remote_mac, np->local_mac, + send_skb->len) < 0) { + kfree_skb(send_skb); + return; + } + + /* + * Fill out the arp protocol part. + * + * we only support ethernet device type, + * which (according to RFC 1390) should always equal 1 (Ethernet). + */ + + arp->ar_hrd = htons(np->dev->type); + arp->ar_pro = htons(ETH_P_IP); + arp->ar_hln = np->dev->addr_len; + arp->ar_pln = 4; + arp->ar_op = htons(type); + + arp_ptr=(unsigned char *)(arp + 1); + memcpy(arp_ptr, np->dev->dev_addr, np->dev->addr_len); + arp_ptr += np->dev->addr_len; + memcpy(arp_ptr, &tip, 4); + arp_ptr += 4; + memcpy(arp_ptr, np->local_mac, np->dev->addr_len); + arp_ptr += np->dev->addr_len; + memcpy(arp_ptr, &sip, 4); + + netpoll_send_skb(np, send_skb); +} + +int netpoll_rx(struct sk_buff *skb) +{ + int proto, len, ulen; + struct iphdr *iph; + struct udphdr *uh; + struct netpoll *np; + struct list_head *p; + unsigned long flags; + + if (skb->dev->type != ARPHRD_ETHER) + goto out; + + /* check if netpoll clients need ARP */ + if (skb->protocol == __constant_htons(ETH_P_ARP) && trapped) { + arp_reply(skb); + return 1; + } + + proto = ntohs(skb->mac.ethernet->h_proto); + if (proto != ETH_P_IP) + goto out; + if (skb->pkt_type == PACKET_OTHERHOST) + goto out; + if (skb_shared(skb)) + goto out; + + iph = (struct iphdr *)skb->data; + if (!pskb_may_pull(skb, sizeof(struct iphdr))) + goto out; + if (iph->ihl < 5 || iph->version != 4) + goto out; + if (!pskb_may_pull(skb, iph->ihl*4)) + goto out; + if (ip_fast_csum((u8 *)iph, iph->ihl) != 0) + goto out; + + len = ntohs(iph->tot_len); + if (skb->len < len || len < iph->ihl*4) + goto out; + + if (iph->protocol != IPPROTO_UDP) + goto out; + + len -= iph->ihl*4; + uh = (struct udphdr *)(((char *)iph) + iph->ihl*4); + ulen = ntohs(uh->len); + + if (ulen != len) + goto out; + if (checksum_udp(skb, uh, ulen, iph->saddr, iph->daddr) < 0) + goto out; + + spin_lock_irqsave(&rx_list_lock, flags); + list_for_each(p, &rx_list) { + np = list_entry(p, struct netpoll, rx_list); + if (np->dev && np->dev != skb->dev) + continue; + if (np->local_ip && np->local_ip != ntohl(iph->daddr)) + continue; + if (np->remote_ip && np->remote_ip != ntohl(iph->saddr)) + continue; + if (np->local_port && np->local_port != ntohs(uh->dest)) + continue; + + spin_unlock_irqrestore(&rx_list_lock, flags); + + if (np->rx_hook) + np->rx_hook(np, ntohs(uh->source), + (char *)(uh+1), ulen-sizeof(uh)-4); + + return 1; + } + spin_unlock_irqrestore(&rx_list_lock, flags); + +out: + return trapped; +} + +int netpoll_parse_options(struct netpoll *np, char *opt) +{ + char *cur=opt, *delim; + + if(*cur != '@') { + if ((delim = strchr(cur, '@')) == NULL) + goto parse_failed; + *delim=0; + np->local_port=simple_strtol(cur, 0, 10); + cur=delim; + } + cur++; + printk(KERN_INFO "%s: local port %d\n", np->name, np->local_port); + + if(*cur != '/') { + if ((delim = strchr(cur, '/')) == NULL) + goto parse_failed; + *delim=0; + np->local_ip=ntohl(in_aton(cur)); + cur=delim; + + printk(KERN_INFO "%s: local IP %d.%d.%d.%d\n", + np->name, HIPQUAD(np->local_ip)); + } + cur++; + + if ( *cur != ',') { + /* parse out dev name */ + if ((delim = strchr(cur, ',')) == NULL) + goto parse_failed; + *delim=0; + strlcpy(np->dev_name, cur, sizeof(np->dev_name)); + cur=delim; + } + cur++; + + printk(KERN_INFO "%s: interface %s\n", np->name, np->dev_name); + + if ( *cur != '@' ) { + /* dst port */ + if ((delim = strchr(cur, '@')) == NULL) + goto parse_failed; + *delim=0; + np->remote_port=simple_strtol(cur, 0, 10); + cur=delim; + } + cur++; + printk(KERN_INFO "%s: remote port %d\n", np->name, np->remote_port); + + /* dst ip */ + if ((delim = strchr(cur, '/')) == NULL) + goto parse_failed; + *delim=0; + np->remote_ip=ntohl(in_aton(cur)); + cur=delim+1; + + printk(KERN_INFO "%s: remote IP %d.%d.%d.%d\n", + np->name, HIPQUAD(np->remote_ip)); + + if( *cur != 0 ) + { + /* MAC address */ + if ((delim = strchr(cur, ':')) == NULL) + goto parse_failed; + *delim=0; + np->remote_mac[0]=simple_strtol(cur, 0, 16); + cur=delim+1; + if ((delim = strchr(cur, ':')) == NULL) + goto parse_failed; + *delim=0; + np->remote_mac[1]=simple_strtol(cur, 0, 16); + cur=delim+1; + if ((delim = strchr(cur, ':')) == NULL) + goto parse_failed; + *delim=0; + np->remote_mac[2]=simple_strtol(cur, 0, 16); + cur=delim+1; + if ((delim = strchr(cur, ':')) == NULL) + goto parse_failed; + *delim=0; + np->remote_mac[3]=simple_strtol(cur, 0, 16); + cur=delim+1; + if ((delim = strchr(cur, ':')) == NULL) + goto parse_failed; + *delim=0; + np->remote_mac[4]=simple_strtol(cur, 0, 16); + cur=delim+1; + np->remote_mac[5]=simple_strtol(cur, 0, 16); + } + + printk(KERN_INFO "%s: remote ethernet address " + "%02x:%02x:%02x:%02x:%02x:%02x\n", + np->name, + np->remote_mac[0], + np->remote_mac[1], + np->remote_mac[2], + np->remote_mac[3], + np->remote_mac[4], + np->remote_mac[5]); + + return 0; + + parse_failed: + printk(KERN_INFO "%s: couldn't parse config at %s!\n", + np->name, cur); + return -1; +} + +int netpoll_setup(struct netpoll *np) +{ + struct net_device *ndev = NULL; + struct in_device *in_dev; + + if (np->dev_name) + ndev = dev_get_by_name(np->dev_name); + if (!ndev) { + printk(KERN_ERR "%s: %s doesn't exist, aborting.\n", + np->name, np->dev_name); + goto release; + } + if (!ndev->poll_controller) { + printk(KERN_ERR "%s: %s doesn't support polling, aborting.\n", + np->name, np->dev_name); + goto release; + } + + if (!(ndev->flags & IFF_UP)) { + unsigned short oflags; + unsigned long jiff; + + printk(KERN_INFO "%s: device %s not up yet, forcing it\n", + np->name, np->dev_name); + + oflags = ndev->flags; + + rtnl_shlock(); + if (dev_change_flags(ndev, oflags | IFF_UP) < 0) { + printk(KERN_ERR "%s: failed to open %s\n", + np->name, np->dev_name); + rtnl_shunlock(); + goto release; + } + rtnl_shunlock(); + + jiff = jiffies + 6*HZ; + while(!netif_carrier_ok(ndev)) { + if (!time_before(jiffies, jiff)) { + printk(KERN_NOTICE + "%s: timeout waiting for carrier\n", + np->name); + break; + } + cond_resched(); + } + + } + + if (!memcmp(np->local_mac, "\0\0\0\0\0\0", 6) && ndev->dev_addr) + memcpy(np->local_mac, ndev->dev_addr, 6); + + if (!np->local_ip) { + in_dev = in_dev_get(ndev); + + if (!in_dev) { + printk(KERN_ERR "%s: no IP address for %s, aborting\n", + np->name, np->dev_name); + goto release; + } + + np->local_ip = ntohl(in_dev->ifa_list->ifa_local); + in_dev_put(in_dev); + printk(KERN_INFO "%s: local IP %d.%d.%d.%d\n", + np->name, HIPQUAD(np->local_ip)); + } + + np->dev = ndev; + + if(np->rx_hook) { + unsigned long flags; + + np->dev->netpoll_rx = 1; + + spin_lock_irqsave(&rx_list_lock, flags); + list_add(&np->rx_list, &rx_list); + spin_unlock_irqrestore(&rx_list_lock, flags); + } + + return 0; + release: + dev_put(ndev); + return -1; +} + +void netpoll_cleanup(struct netpoll *np) +{ + if(np->rx_hook) { + unsigned long flags; + + spin_lock_irqsave(&rx_list_lock, flags); + list_del(&np->rx_list); + np->dev->netpoll_rx = 0; + spin_unlock_irqrestore(&rx_list_lock, flags); + } + + dev_put(np->dev); + np->dev = 0; +} + +int netpoll_trap() +{ + return trapped; +} + +void netpoll_set_trap(int trap) +{ + trapped = trap; +} + +EXPORT_SYMBOL(netpoll_set_trap); +EXPORT_SYMBOL(netpoll_trap); +EXPORT_SYMBOL(netpoll_parse_options); +EXPORT_SYMBOL(netpoll_setup); +EXPORT_SYMBOL(netpoll_cleanup); +EXPORT_SYMBOL(netpoll_send_skb); +EXPORT_SYMBOL(netpoll_send_udp); +EXPORT_SYMBOL(netpoll_poll); diff -puN /dev/null include/linux/netpoll.h --- /dev/null 2003-09-12 12:14:37.000000000 -0500 +++ ml-mpm/include/linux/netpoll.h 2003-10-02 16:48:38.000000000 -0500 @@ -0,0 +1,38 @@ +/* + * Common code for low-level network console, dump, and debugger code + * + * Derived from netconsole, kgdb-over-ethernet, and netdump patches + */ + +#ifndef _LINUX_NETPOLL_H +#define _LINUX_NETPOLL_H + +#include +#include +#include +#include + +struct netpoll; + +struct netpoll { + struct net_device *dev; + char dev_name[16], *name; + void (*rx_hook)(struct netpoll *, int, char *, int); + u32 local_ip, remote_ip; + u16 local_port, remote_port; + unsigned char local_mac[6], remote_mac[6]; + struct list_head rx_list; +}; + +void netpoll_poll(struct netpoll *np); +void netpoll_send_skb(struct netpoll *np, struct sk_buff *skb); +void netpoll_send_udp(struct netpoll *np, const char *msg, int len); +int netpoll_parse_options(struct netpoll *np, char *opt); +int netpoll_setup(struct netpoll *np); +int netpoll_trap(void); +void netpoll_set_trap(int trap); +void netpoll_cleanup(struct netpoll *np); +int netpoll_rx(struct sk_buff *skb); + + +#endif diff -puN net/core/Makefile~netpoll-core net/core/Makefile --- ml/net/core/Makefile~netpoll-core 2003-10-02 16:48:38.000000000 -0500 +++ ml-mpm/net/core/Makefile 2003-10-02 16:48:38.000000000 -0500 @@ -13,3 +13,4 @@ obj-$(CONFIG_NETFILTER) += netfilter.o obj-$(CONFIG_NET_DIVERT) += dv.o obj-$(CONFIG_NET_PKTGEN) += pktgen.o obj-$(CONFIG_NET_RADIO) += wireless.o +obj-$(CONFIG_NETPOLL) += netpoll.o diff -puN net/Kconfig~netpoll-core net/Kconfig --- ml/net/Kconfig~netpoll-core 2003-10-02 16:48:38.000000000 -0500 +++ ml-mpm/net/Kconfig 2003-10-02 16:48:38.000000000 -0500 @@ -670,4 +670,15 @@ source "net/irda/Kconfig" source "net/bluetooth/Kconfig" +config NETPOLL + bool "Netpoll API" + +config NETPOLL_RX + bool "Netpoll receive hooks" + depends on NETPOLL + +config NETPOLL_TRAP + bool "Netpoll traffic trapping" + depends on NETPOLL + endmenu diff -puN include/linux/netdevice.h~netpoll-core include/linux/netdevice.h --- ml/include/linux/netdevice.h~netpoll-core 2003-10-02 16:48:38.000000000 -0500 +++ ml-mpm/include/linux/netdevice.h 2003-10-02 16:48:38.000000000 -0500 @@ -452,6 +452,11 @@ struct net_device unsigned char *haddr); int (*neigh_setup)(struct net_device *dev, struct neigh_parms *); int (*accept_fastpath)(struct net_device *, struct dst_entry*); +#ifdef CONFIG_NETPOLL_RX +#define HAVE_POLL_CONTROLLER + int netpoll_rx; + void (*poll_controller)(struct net_device *dev); +#endif /* bridge stuff */ struct net_bridge_port *br_port; @@ -530,6 +535,9 @@ extern int dev_new_index(void); extern struct net_device *dev_get_by_index(int ifindex); extern struct net_device *__dev_get_by_index(int ifindex); extern int dev_restart(struct net_device *dev); +#ifdef CONFIG_NETPOLL_TRAP +extern int netpoll_trap(void); +#endif typedef int gifconf_func_t(struct net_device * dev, char * bufptr, int len); extern int register_gifconf(unsigned int family, gifconf_func_t * gifconf); @@ -588,12 +596,20 @@ static inline void netif_start_queue(str static inline void netif_wake_queue(struct net_device *dev) { +#ifdef CONFIG_NETPOLL_TRAP + if (netpoll_trap()) + return; +#endif if (test_and_clear_bit(__LINK_STATE_XOFF, &dev->state)) __netif_schedule(dev); } static inline void netif_stop_queue(struct net_device *dev) { +#ifdef CONFIG_NETPOLL_TRAP + if (netpoll_trap()) + return; +#endif set_bit(__LINK_STATE_XOFF, &dev->state); } diff -puN net/core/dev.c~netpoll-core net/core/dev.c --- ml/net/core/dev.c~netpoll-core 2003-10-02 16:48:38.000000000 -0500 +++ ml-mpm/net/core/dev.c 2003-10-02 16:48:38.000000000 -0500 @@ -105,6 +105,7 @@ #include #include #include +#include #ifdef CONFIG_NET_RADIO #include /* Note : will define WIRELESS_EXT */ #include @@ -1347,6 +1348,13 @@ int netif_rx(struct sk_buff *skb) struct softnet_data *queue; unsigned long flags; +#ifdef CONFIG_NETPOLL_RX + if (skb->dev->netpoll_rx && netpoll_rx(skb)) { + kfree_skb(skb); + return NET_RX_DROP; + } +#endif + if (!skb->stamp.tv_sec) do_gettimeofday(&skb->stamp); @@ -1531,6 +1539,13 @@ int netif_receive_skb(struct sk_buff *sk int ret = NET_RX_DROP; unsigned short type = skb->protocol; +#ifdef CONFIG_NETPOLL_RX + if (skb->dev->netpoll_rx && skb->dev->poll && netpoll_rx(skb)) { + kfree_skb(skb); + return NET_RX_DROP; + } +#endif + if (!skb->stamp.tv_sec) do_gettimeofday(&skb->stamp); diff -puN arch/i386/kernel/irq.c~netpoll-core arch/i386/kernel/irq.c _ -- Matt Mackall : http://www.selenic.com : of or relating to the moon From oxymoron@waste.org Thu Oct 2 18:45:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 18:45:48 -0700 (PDT) Received: from waste.org (waste.org [209.173.204.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h931jE25006307 for ; Thu, 2 Oct 2003 18:45:14 -0700 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id h931j6RT024772; Thu, 2 Oct 2003 20:45:06 -0500 Received: (from oxymoron@localhost) by waste.org (8.12.3/8.12.3/Debian-6.6) id h931j60s024770; Thu, 2 Oct 2003 20:45:06 -0500 Date: Thu, 2 Oct 2003 20:45:05 -0500 From: Matt Mackall To: netdev@oss.sgi.com Cc: Andrew Morton , Jeff Garzik Subject: [RFC] [PATCH 2/3] tg3 netpoll hook Message-ID: <20031003014505.GS1897@waste.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new X-archive-position: 481 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev l-mpm/drivers/net/tg3.c | 16 ++++++++++++++++ 1 files changed, 16 insertions(+) diff -puN drivers/net/tg3.c~tg3-poll drivers/net/tg3.c --- l/drivers/net/tg3.c~tg3-poll 2003-09-25 11:47:30.000000000 -0500 +++ l-mpm/drivers/net/tg3.c 2003-09-25 11:56:37.000000000 -0500 @@ -2475,6 +2475,15 @@ static irqreturn_t tg3_interrupt(int irq static int tg3_init_hw(struct tg3 *); static int tg3_halt(struct tg3 *); +#ifdef HAVE_POLL_CONTROLLER +static void tg3_poll_controller(struct net_device *dev) +{ + disable_irq(dev->irq); + tg3_interrupt (dev->irq, dev, NULL); + enable_irq(dev->irq); +} +#endif + static void tg3_reset_task(void *_data) { struct tg3 *tp = _data; @@ -7482,6 +7491,10 @@ static struct pci_dev * __devinit tg3_fi return peer; } +#ifdef HAVE_POLL_CONTROLLER +static void tg3_poll_controller(struct net_device *dev); +#endif + static int __devinit tg3_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) { @@ -7632,6 +7645,9 @@ static int __devinit tg3_init_one(struct dev->watchdog_timeo = TG3_TX_TIMEOUT; dev->change_mtu = tg3_change_mtu; dev->irq = pdev->irq; +#ifdef HAVE_POLL_CONTROLLER + dev->poll_controller = tg3_poll_controller; +#endif err = tg3_get_invariants(tp); if (err) { _ -- Matt Mackall : http://www.selenic.com : of or relating to the moon From oxymoron@waste.org Thu Oct 2 18:52:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 18:52:57 -0700 (PDT) Received: from waste.org (waste.org [209.173.204.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h931qK25006667 for ; Thu, 2 Oct 2003 18:52:21 -0700 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id h931qCRT025206; Thu, 2 Oct 2003 20:52:12 -0500 Received: (from oxymoron@localhost) by waste.org (8.12.3/8.12.3/Debian-6.6) id h931qCO8025204; Thu, 2 Oct 2003 20:52:12 -0500 Date: Thu, 2 Oct 2003 20:52:12 -0500 From: Matt Mackall To: netdev@oss.sgi.com Cc: Andrew Morton , Jeff Garzik Subject: [RFC] [PATCH 3/3] netconsole using netpoll Message-ID: <20031003015212.GU1897@waste.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new X-archive-position: 482 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev This patch uses the netpoll API to transmit kernel printks over UDP ml-mpm/Documentation/networking/netconsole.txt | 57 +++++++++++ ml-mpm/drivers/net/Kconfig | 7 + ml-mpm/drivers/net/Makefile | 1 ml-mpm/drivers/net/netconsole.c | 129 +++++++++++++++++++++++++ ml-mpm/net/Kconfig | 5 5 files changed, 196 insertions(+), 3 deletions(-) diff -puN -L net/core/netconsole.c /dev/null /dev/null diff -puN net/core/Makefile~netconsole net/core/Makefile diff -puN net/Kconfig~netconsole net/Kconfig --- ml/net/Kconfig~netconsole 2003-10-02 17:56:34.000000000 -0500 +++ ml-mpm/net/Kconfig 2003-10-02 17:56:34.000000000 -0500 @@ -671,11 +671,10 @@ source "net/irda/Kconfig" source "net/bluetooth/Kconfig" config NETPOLL - bool "Netpoll API" + def_bool NETCONSOLE config NETPOLL_RX - bool "Netpoll receive hooks" - depends on NETPOLL + def_bool NETCONSOLE config NETPOLL_TRAP bool "Netpoll traffic trapping" diff -puN /dev/null Documentation/networking/netconsole.txt --- /dev/null 2003-09-12 12:14:37.000000000 -0500 +++ ml-mpm/Documentation/networking/netconsole.txt 2003-10-02 17:56:34.000000000 -0500 @@ -0,0 +1,57 @@ + +started by Ingo Molnar , 2001.09.17 +2.6 port and netpoll api by Matt Mackall , Sep 9 2003 + +Please send bug reports to Matt Mackall + +This module logs kernel printk messages over UDP allowing debugging of +problem where disk logging fails and serial consoles are impractical. + +It can be used either built-in or as a module. As a built-in, +netconsole initializes immediately after NIC cards and will bring up +the specified interface as soon as possible. While this doesn't allow +capture of early kernel panics, it does capture most of the boot +process. + +It takes a string configuration parameter "netconsole" in the +following format: + + netconsole=[src-port]@[src-ip]/[],[tgt-port]@/[tgt-macaddr] + + where + src-port source for UDP packets (defaults to 6665) + src-ip source IP to use (interface address) + dev network interface (eth0) + tgt-port port for logging agent (6666) + tgt-ip IP address for logging agent + tgt-macaddr ethernet MAC address for logging agent (broadcast) + +Examples: + + linux netconsole=4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc + + or + + insmod netconsole netconsole=@/,@10.0.0.2/ + +Built-in netconsole starts immediately after the TCP stack is +initialized and attempts to bring up the supplied dev at the supplied +address. + +The remote host can run either 'netcat -u -l -p ' or syslogd. + +WARNING: the default target ethernet setting uses the broadcast +ethernet address to send packets, which can cause increased load on +other systems on the same ethernet segment. + +NOTE: the network device (eth1 in the above case) can run any kind +of other network traffic, netconsole is not intrusive. Netconsole +might cause slight delays in other traffic if the volume of kernel +messages is high, but should have no other impact. + +Netconsole was designed to be as instantaneous as possible, to +enable the logging of even the most critical kernel bugs. It works +from IRQ contexts as well, and does not enable interrupts while +sending packets. Due to these unique needs, configuration can not +be more automatic, and some fundamental limitations will remain: +only IP networks, UDP packets and ethernet devices are supported. diff -puN drivers/net/Makefile~netconsole drivers/net/Makefile --- ml/drivers/net/Makefile~netconsole 2003-10-02 17:56:34.000000000 -0500 +++ ml-mpm/drivers/net/Makefile 2003-10-02 17:57:25.000000000 -0500 @@ -188,3 +188,4 @@ obj-$(CONFIG_NET_TULIP) += tulip/ obj-$(CONFIG_HAMRADIO) += hamradio/ obj-$(CONFIG_IRDA) += irda/ +obj-$(CONFIG_NETCONSOLE) += netconsole.o diff -puN drivers/net/Kconfig~netconsole drivers/net/Kconfig --- ml/drivers/net/Kconfig~netconsole 2003-10-02 17:56:34.000000000 -0500 +++ ml-mpm/drivers/net/Kconfig 2003-10-02 17:56:34.000000000 -0500 @@ -2455,6 +2455,13 @@ config SHAPER To compile this driver as a module, choose M here: the module will be called shaper. If unsure, say N. +config NETCONSOLE + tristate "Network console logging support" + depends on NETDEVICES + ---help--- + If you want to log kernel messages over the network, enable this. + See Documentation/networking/netconsole.txt for details. + source "drivers/net/wan/Kconfig" source "drivers/net/pcmcia/Kconfig" diff -puN /dev/null drivers/net/netconsole.c --- /dev/null 2003-09-12 12:14:37.000000000 -0500 +++ ml-mpm/drivers/net/netconsole.c 2003-10-02 17:56:34.000000000 -0500 @@ -0,0 +1,129 @@ +/* + * linux/drivers/net/netconsole.c + * + * Copyright (C) 2001 Ingo Molnar + * + * This file contains the implementation of an IRQ-safe, crash-safe + * kernel console implementation that outputs kernel messages to the + * network. + * + * Modification history: + * + * 2001-09-17 started by Ingo Molnar. + * 2003-08-11 2.6 port by Matt Mackall + * simplified options + * generic card hooks + * works non-modular + * 2003-09-07 rewritten with netpoll api + */ + +/**************************************************************** + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + * + ****************************************************************/ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +MODULE_AUTHOR("Maintainer: Matt Mackall "); +MODULE_DESCRIPTION("Console driver for network interfaces"); +MODULE_LICENSE("GPL"); + +static char config[256]; +module_param_string(netconsole, config, 256, 0); +MODULE_PARM_DESC(netconsole, " netconsole=[src-port]@[src-ip]/[dev],[tgt-port]@/[tgt-macaddr]\n"); + +static void rx_hook(struct netpoll *np, int port, char *msg, int len); + +static struct netpoll np = { + .name = "netconsole", + .dev_name = "eth0", + .rx_hook = rx_hook, + .local_port = 6665, + .remote_port = 6666, + .remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff}, +}; + +#define MAX_PRINT_CHUNK 1000 + +static void write_msg(struct console *con, const char *msg, unsigned int len) +{ + int frag, left; + unsigned long flags; + + if (!np.dev) + return; + + local_irq_save(flags); + + for(left = len; left; ) { + frag = min(left, MAX_PRINT_CHUNK); + netpoll_send_udp(&np, msg, frag); + msg += frag; + left -= frag; + } + + local_irq_restore(flags); +} + +static void rx_hook(struct netpoll *np, int port, char *msg, int len) +{ + /* add sysrq support */ + printk("netconsole: no sysrq yet\n"); +} + +static struct console netconsole = { + .flags = CON_ENABLED | CON_PRINTBUFFER, + .write = write_msg +}; + +static int option_setup(char *opt) +{ + return netpoll_parse_options(&np, opt); +} + +__setup("netconsole=", option_setup); + +static int init_netconsole(void) +{ + if(strlen(config) && option_setup(config)) + return 1; + + if(!np.remote_ip || netpoll_setup(&np)) + return 1; + + register_console(&netconsole); + printk(KERN_INFO "netconsole: network logging started\n"); + return 0; +} + +static void cleanup_netconsole(void) +{ + unregister_console(&netconsole); + netpoll_cleanup(&np); +} + +module_init(init_netconsole); +module_exit(cleanup_netconsole); _ -- Matt Mackall : http://www.selenic.com : of or relating to the moon From mitch@sfgoth.com Thu Oct 2 19:17:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 19:17:58 -0700 (PDT) Received: from gaz.sfgoth.com ([63.205.85.133]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h932HO25007259 for ; Thu, 2 Oct 2003 19:17:24 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.9p1/8.12.9) with ESMTP id h932QG16043306; Thu, 2 Oct 2003 19:26:16 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.9p1/8.12.6/Submit) id h932QFLd043302; Thu, 2 Oct 2003 19:26:15 -0700 (PDT) (envelope-from mitch) Date: Thu, 2 Oct 2003 19:26:15 -0700 From: Mitchell Blank Jr To: "David S. Miller" Cc: chas3@users.sourceforge.net, chas@cmf.nrl.navy.mil, netdev@oss.sgi.com Subject: Re: [RFC] add rtnl semaphore to linux-atm Message-ID: <20031003022615.GA42593@gaz.sfgoth.com> References: <200310011134.h91BYPkT003172@ginger.cmf.nrl.navy.mil> <20031001054226.126cea7b.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031001054226.126cea7b.davem@redhat.com> User-Agent: Mutt/1.4.1i X-archive-position: 483 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev David S. Miller wrote: > Although, unless VCC connect can potentially sleep, it might > be better to keep exporting the rwlock and take it as a reader > instead of grabbing the rtnl semaphore. VCC connect can definately sleep - a good example is drirvers/usb/misc/speedtch.c but there are probably other ones. My personal recommendations: * There should be a per-atm-device semaphore held across calls into the driver's ->open, ->close, ->change_qos and maybe a couple other things to serialize those operations (for the sake of keeping the drivers sane - there's no reason there should be multiple operations pending) * The ATM layer shouldn't need to keep any other sorts of locks across calls into atm_dev->open or such. To avoid race conditions the ATM code needs to: 1. Take whatever internal spinlock it needs 2. Add the itf/vpi/vci tuple to whatever datastructure we're holding the vcc list in - but mark it as "inactive" so we don't find it while others are searching the list. Obviously the open will fail if we find a matching tuple (whether or not it was active) 3. Drop the spinlock 4. Take the per-device semaphore 5. Call atmdev->open 6. Drop the per-device semaphore 7. Re-take the internal spinlock 8. If open succeeded now mark the vcc as "active". If the open failed just delete it 9. Drop the internal spinlock To do a close the method is similar: 1. Take the internal spinlock 2. Find the tuple, mark it as inactive 3. Drop the spinlock 4. Take the per-device semaphore 5. Call atmdev->close 6. Drop the per-device semaphore 7. Re-take the internal spinlock 8. Delete vcc from the list 9. Drop the internal spinlock Then ->open and ->close can sleep like they need to but won't block other accesses to the list in the mean time. * If ATM_ITF_ANY is a pain to fix it should just be removed - it's basically a misfeature and is probably never used by anybody. I've already posted a patch to linux-atm-general that basically does this (it changes "ATM_ITF_ANY" to mean "first interface we find") -Mitch From jgarzik@pobox.com Thu Oct 2 19:20:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 19:20:57 -0700 (PDT) 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 h932KM25007608 for ; Thu, 2 Oct 2003 19:20:23 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:35554 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 1A57YV-0005f4-J0; Thu, 02 Oct 2003 18:47:59 +0100 Message-ID: <3F7C64BC.7030701@pobox.com> Date: Thu, 02 Oct 2003 13:47:40 -0400 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: Robert Olsson , Andrew Morton CC: netdev@oss.sgi.com, dfages@arkoon.net Subject: Re: Fw: [BUG/PATCH] CONFIG_NET_HW_FLOWCONTROL and SMP References: <20030929123734.5bd97a47.akpm@osdl.org> <16248.41796.797321.700866@robur.slu.se> <3F78A691.1040406@pobox.com> <16252.17618.866515.952549@robur.slu.se> In-Reply-To: <16252.17618.866515.952549@robur.slu.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 484 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 Robert Olsson wrote: > > Jeff Garzik writes: > > > > If someone had a NAPI patch for tulip, we could remove HW_FLOWCONTROL > > option altogether :) > > Hello! > Here is something for 2.6.0-test6: > > * ifdef's to keep current non-NAPI tulip intact > > * Port based on Alexey's orig NAPI tulip design > (Only RX handled by dev->poll) > > * tulip HW_FLOW removed > > * NAPI and HW-mitigation options in Kconfig Looks great to me. I'll give it some testing here, and 99% likely will apply it. Andrew, would you be willing to merge this into -mm for some simultaneous netwide testing? FWIW, I seem to recall that the older NAPI patch you sent didn't apply for some reason. But forget about that, this one looks good. Jeff From mitch@sfgoth.com Thu Oct 2 19:25:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 19:26:10 -0700 (PDT) Received: from gaz.sfgoth.com ([63.205.85.133]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h932Pa25007969 for ; Thu, 2 Oct 2003 19:25:36 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.9p1/8.12.9) with ESMTP id h932YW16044036; Thu, 2 Oct 2003 19:34:32 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.9p1/8.12.6/Submit) id h932YVZs044035; Thu, 2 Oct 2003 19:34:31 -0700 (PDT) (envelope-from mitch) Date: Thu, 2 Oct 2003 19:34:31 -0700 From: Mitchell Blank Jr To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] skbuff more likely/unlikely Message-ID: <20031003023431.GC42593@gaz.sfgoth.com> References: <20031002102420.6e1cece9.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031002102420.6e1cece9.shemminger@osdl.org> User-Agent: Mutt/1.4.1i X-archive-position: 485 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev Stephen Hemminger wrote: > A couple more places where we can help by hinting the compiler > for 2.6.0-test6. If we are pulling off header, is is likely there; > and skb alloc's succeed in the normal case. > > Thought I saw an earlier similar patch, but here is my take on it. Yes, my patch from a couple weeks ago does the same thing (but also did a lot in skbuff.c) I haven't had a chance to rediff and test after the const parts went in. Do you want to adopt the rest of the changes? Original patch: http://oss.sgi.com/projects/netdev/archive/2003-09/msg00036.html -Mitch From davem@pizda.ninka.net Thu Oct 2 23:44:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Oct 2003 23:45:31 -0700 (PDT) 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 h936iv25023492 for ; Thu, 2 Oct 2003 23:44:57 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA22163; Thu, 2 Oct 2003 23:40:36 -0700 Date: Thu, 2 Oct 2003 23:40:36 -0700 From: "David S. Miller" To: Steve Modica Cc: netdev@oss.sgi.com Subject: Re: mod_timer improvement Message-Id: <20031002234036.704c4588.davem@redhat.com> In-Reply-To: <3F7C5D22.7010103@sgi.com> References: <3F7C5863.1080403@sgi.com> <3F7C5D22.7010103@sgi.com> X-Mailer: Sylpheed version 0.9.2 (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: 486 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, 02 Oct 2003 12:15:14 -0500 Steve Modica wrote: > D'OH! Sorry about the formatting. I think this is better: Probably the networking development list isn't the place to post patches that modify generic code such as the timer stuff you are modifying here. From ak@suse.de Fri Oct 3 00:10:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 00:10:37 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h937A125025700 for ; Fri, 3 Oct 2003 00:10:01 -0700 Received: from Hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 5C3DE169D750; Fri, 3 Oct 2003 09:09:55 +0200 (CEST) Date: Fri, 3 Oct 2003 09:09:54 +0200 From: Andi Kleen To: Matt Mackall Cc: netdev@oss.sgi.com, Andrew Morton , Jeff Garzik Subject: Re: [RFC] [PATCH 1/3] netpoll api Message-ID: <20031003070954.GE25013@wotan.suse.de> References: <20031003014104.GR1897@waste.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031003014104.GR1897@waste.org> X-archive-position: 487 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev > The second patch is an example of implementing the poll_controller > hook needed to get a card to work with netpoll. Numerous other examples > are in -mm and recent Red Hat kernels. SuSE/UL kernels also have support for some chips. -Andi From davem@pizda.ninka.net Fri Oct 3 00:15:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 00:16:24 -0700 (PDT) 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 h937Fm25026294 for ; Fri, 3 Oct 2003 00:15:49 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA22289; Fri, 3 Oct 2003 00:11:28 -0700 Date: Fri, 3 Oct 2003 00:11:28 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: ak@suse.de, netdev@oss.sgi.com Subject: Re: [PATCH] consolidate skb delivery Message-Id: <20031003001128.587ac102.davem@redhat.com> In-Reply-To: <20031002124345.7b34bf24.shemminger@osdl.org> References: <20031002102133.7285b5ee.shemminger@osdl.org> <20031002192546.GA29673@wotan.suse.de> <20031002124345.7b34bf24.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (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: 488 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, 2 Oct 2003 12:43:45 -0700 Stephen Hemminger wrote: > On Thu, 2 Oct 2003 21:25:46 +0200 > Andi Kleen wrote: > > > Are there even any old style protocols left? If not you could just make > > it BUG() > > > > bpqether,lapbether,ipconfig, and econet are still old style. I would suggest we eliminate support for old style protocols now. We can do that by making the ptype registry in net/core/dev.c fail if the thing being registered is old-style. I'll code this up. If we don't kill support for old-style protocols now, we can end up being stuck supporting it throughout 2.6.x which I'd like to avoid. I'll apply Stephen's patch here. From davem@pizda.ninka.net Fri Oct 3 00:23:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 00:24:11 -0700 (PDT) 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 h937Na25030065 for ; Fri, 3 Oct 2003 00:23:36 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA22352; Fri, 3 Oct 2003 00:19:16 -0700 Date: Fri, 3 Oct 2003 00:19:16 -0700 From: "David S. Miller" To: Mitchell Blank Jr Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] skbuff more likely/unlikely Message-Id: <20031003001916.570546c4.davem@redhat.com> In-Reply-To: <20031003023431.GC42593@gaz.sfgoth.com> References: <20031002102420.6e1cece9.shemminger@osdl.org> <20031003023431.GC42593@gaz.sfgoth.com> X-Mailer: Sylpheed version 0.9.2 (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: 489 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, 2 Oct 2003 19:34:31 -0700 Mitchell Blank Jr wrote: > Stephen Hemminger wrote: > > A couple more places where we can help by hinting the compiler > > for 2.6.0-test6. If we are pulling off header, is is likely there; > > and skb alloc's succeed in the normal case. > > > > Thought I saw an earlier similar patch, but here is my take on it. > > Yes, my patch from a couple weeks ago does the same thing (but also > did a lot in skbuff.c) I haven't had a chance to rediff and test > after the const parts went in. Do you want to adopt the rest of the > changes? I applied Stephen's patch here, you can post something relative to that if you like. From davem@pizda.ninka.net Fri Oct 3 00:46:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 00:46:38 -0700 (PDT) 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 h937k225032151 for ; Fri, 3 Oct 2003 00:46:02 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA22401; Fri, 3 Oct 2003 00:41:33 -0700 Date: Fri, 3 Oct 2003 00:41:33 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: modica@sgi.com, netdev@oss.sgi.com Subject: Re: do_gettimeofday Message-Id: <20031003004133.3148c39a.davem@redhat.com> In-Reply-To: <20031002125625.72b8c0a7.shemminger@osdl.org> References: <3F7C6F3B.6070502@sgi.com> <20031002125625.72b8c0a7.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (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: 490 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, 2 Oct 2003 12:56:25 -0700 Stephen Hemminger wrote: > It might be possible to introduce a per-cpu monotonic clock that is lockless > for use in network code, but that is a moderately painful undertaking which > is beyond the scope of getting 2.6.0 out. Yes, this issue is well known and it gets brought up again from time to time. And it's by no means just SO_TIMESTAMP that uses the skb->stamp values, even IPV4/IPV6 fragmentation uses these things. The SunRPC and RXRPC layers use it as well. It really is an arch-specific issue of how to "optimize" this the best, that's why it's hard to decide what the interface is that an arch needs to provide. But at the base I say we need three things: 1) Some kind of fast_timestamp_t, the property is that this stores enough information at time "T" such that at time "T + something" the fast_timestamp_t can be converted what the timeval was back at time "T". For networking, make skb->stamp into this type. 2) store_fast_timestamp(fast_timestamp_t *) For networking, change do_gettimeofday(&skb->stamp) into store_fast_timestamp(&skb->stamp) 3) fast_timestamp_to_timeval(arch_timestamp_t *, struct timeval *) For networking, change things that read the skb->stamp value into calls to fast_timestamp_to_timeval(). It is defined that the timeval given by fast_timestamp_to_timeval() needs to be the same thing that do_gettimeofday() would have recorded at the time store_fast_timestamp() was called. Here is the default generic implementation that would go into asm-generic/faststamp.h: 1) fast_timestamp_t is struct timeval 2) store_fast_timestamp() is gettimeofday() 3) fast_timestamp_to_timeval() merely copies the fast_timestamp_t into the passed in timeval. And here is how an example implementation could work on sparc64: 1) fast_timestamp_t is a u64 2) store_fast_timestamp() reads the cpu cycle counter 3) fast_timestamp_to_timeval() records the difference between the current cpu cycle counter and the one recorded, it takes a sample of the current xtime value and adjusts it accordingly to account for the cpu cycle counter difference. This only works because sparc64's cpu cycle counters are synchronized across all cpus, they increase monotonically, and are guarenteed not to overflow for at least 10 years. Alpha, for example, cannot do it this way because it's cpu cycle counter register overflows too quickly to be useful. Platforms with inter-cpu TSC synchronization issues will have some troubles doing the same trick too, because one must handle properly the case where the fast timestamp is converted to a timeval on a different cpu on which the fast timestamp was recorded. Regardless, we could put the infrastructure in there now and arch folks can work on implementations. The generic implementation code, which is what everyone will end up with at first, will cancel out to what we have currently. This is a pretty powerful idea that could be applied to other places, not just the networking. From mitch@sfgoth.com Fri Oct 3 01:17:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 01:18:18 -0700 (PDT) Received: from gaz.sfgoth.com ([63.205.85.133]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h938Hg25002544 for ; Fri, 3 Oct 2003 01:17:42 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.9p1/8.12.9) with ESMTP id h938Qg16053396; Fri, 3 Oct 2003 01:26:42 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.9p1/8.12.6/Submit) id h938QgYj053395; Fri, 3 Oct 2003 01:26:42 -0700 (PDT) (envelope-from mitch) Date: Fri, 3 Oct 2003 01:26:42 -0700 From: Mitchell Blank Jr To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: do_gettimeofday Message-ID: <20031003082642.GF42593@gaz.sfgoth.com> References: <3F7C6F3B.6070502@sgi.com> <20031002125625.72b8c0a7.shemminger@osdl.org> <20031003004133.3148c39a.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031003004133.3148c39a.davem@redhat.com> User-Agent: Mutt/1.4.1i X-archive-position: 491 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev David S. Miller wrote: > 3) fast_timestamp_to_timeval(arch_timestamp_t *, struct timeval *) > > For networking, change things that read the skb->stamp value > into calls to fast_timestamp_to_timeval(). Are there any common cases where skb->stamp is looked at more than once? If so I might recommend changing the API to be more like: const struct timeval *skb_timestamp(struct skbuff *skb); where the generic form would just be: typedef struct { struct timeval tv; } fast_timestamp_t; static inline const struct timeval *skb_timestamp(struct skbuff *skb) { return &skb->faststamp.tv; } ...but an arch could accelerate it with: typedef struct { union { struct timeval tv; u64 tsc; } int is_converted; } fast_timestamp_t; /* Caller must be sure we have exclusive ownership of this skbuff */ const struct timeval *skb_timestamp(struct skbuff *skb) { if (!skb->faststamp.is_converted) { tsc_to_timeval(&skb->faststamp.tv, skb->faststamp.tsc); skb->faststamp.is_converted = 1; } return &skb->faststamp.tv; } If we could hide "is_converted" as a flag somewhere else this would have zero storage penalty (since most archs would have a fast-stamp at least as big as a timeval) I dunno, just an idea. > Platforms with inter-cpu TSC synchronization issues will have some > troubles doing the same trick too, because one must handle properly > the case where the fast timestamp is converted to a timeval on a different > cpu on which the fast timestamp was recorded. Yeah, you'd probably have something like typedef struct { union { struct timeval tv; struct { u64 tsc; #ifdef CONFIG_SMP unsigned int cpu_id; #endif /* CONFIG_SMP */ } fast; } int is_converted; } fast_timestamp_t; And then skb_timestamp() would have to rummage around in the per-cpu timer state for whatever processor started the packet. (This is why I thought it might be good to cache the result - you don't want to thrash those cachelines more than once if you can help it) -Mitch From davem@pizda.ninka.net Fri Oct 3 01:32:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 01:32:50 -0700 (PDT) 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 h938WF25003855 for ; Fri, 3 Oct 2003 01:32:15 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id BAA22654; Fri, 3 Oct 2003 01:27:54 -0700 Date: Fri, 3 Oct 2003 01:27:54 -0700 From: "David S. Miller" To: Mitchell Blank Jr Cc: netdev@oss.sgi.com Subject: Re: do_gettimeofday Message-Id: <20031003012754.23de3f66.davem@redhat.com> In-Reply-To: <20031003082642.GF42593@gaz.sfgoth.com> References: <3F7C6F3B.6070502@sgi.com> <20031002125625.72b8c0a7.shemminger@osdl.org> <20031003004133.3148c39a.davem@redhat.com> <20031003082642.GF42593@gaz.sfgoth.com> X-Mailer: Sylpheed version 0.9.2 (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: 492 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, 3 Oct 2003 01:26:42 -0700 Mitchell Blank Jr wrote: > Are there any common cases where skb->stamp is looked at more than > once? Yes, the packet scheduler can cause this to happen. >If so I might recommend changing the API to be more like: > > const struct timeval *skb_timestamp(struct skbuff *skb); Please no, making this a SKB or networking specific interface make it nearly valueless and we might as well just stay with the stuff we have. > > Platforms with inter-cpu TSC synchronization issues will have some > > troubles doing the same trick too, because one must handle properly > > the case where the fast timestamp is converted to a timeval on a different > > cpu on which the fast timestamp was recorded. > > Yeah, you'd probably have something like Doesn't work as-is. You'd have to not only store the timestamp and the cpu it was stored on, but also cross-call to that cpu to compute the correct timeval. That's really expensive and probably do_gettimeofday() is going to be faster in the long run compared to such a scheme. From mitch@sfgoth.com Fri Oct 3 01:39:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 01:40:23 -0700 (PDT) Received: from gaz.sfgoth.com ([63.205.85.133]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h938dm25004673 for ; Fri, 3 Oct 2003 01:39:48 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.9p1/8.12.9) with ESMTP id h938mm16054045; Fri, 3 Oct 2003 01:48:48 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.9p1/8.12.6/Submit) id h938mlVC054044; Fri, 3 Oct 2003 01:48:47 -0700 (PDT) (envelope-from mitch) Date: Fri, 3 Oct 2003 01:48:47 -0700 From: Mitchell Blank Jr To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: do_gettimeofday Message-ID: <20031003084847.GH42593@gaz.sfgoth.com> References: <3F7C6F3B.6070502@sgi.com> <20031002125625.72b8c0a7.shemminger@osdl.org> <20031003004133.3148c39a.davem@redhat.com> <20031003082642.GF42593@gaz.sfgoth.com> <20031003012754.23de3f66.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031003012754.23de3f66.davem@redhat.com> User-Agent: Mutt/1.4.1i X-archive-position: 493 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev David S. Miller wrote: > Doesn't work as-is. You'd have to not only store the timestamp and > the cpu it was stored on, but also cross-call to that cpu to compute > the correct timeval. That's definately the worst case. You could have each CPU periodically store its current {tsc,timeval} tuple in a per-cpu location and extrapolate from that. > That's really expensive and probably > do_gettimeofday() is going to be faster in the long run compared to > such a scheme. It all depends on what percentage of skb's have ->stamp computed on a CPU different from the one they came it on. For the common users of ->stamp won't they have stayed on the same CPU? The worst case of doing a cross-cpu-call should only happen relatively rarely. -Mitch From davem@pizda.ninka.net Fri Oct 3 01:56:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 01:57:14 -0700 (PDT) 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 h938ue25006082 for ; Fri, 3 Oct 2003 01:56:41 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id BAA22729; Fri, 3 Oct 2003 01:52:20 -0700 Date: Fri, 3 Oct 2003 01:52:20 -0700 From: "David S. Miller" To: Mitchell Blank Jr Cc: netdev@oss.sgi.com Subject: Re: do_gettimeofday Message-Id: <20031003015220.7ee6e451.davem@redhat.com> In-Reply-To: <20031003084847.GH42593@gaz.sfgoth.com> References: <3F7C6F3B.6070502@sgi.com> <20031002125625.72b8c0a7.shemminger@osdl.org> <20031003004133.3148c39a.davem@redhat.com> <20031003082642.GF42593@gaz.sfgoth.com> <20031003012754.23de3f66.davem@redhat.com> <20031003084847.GH42593@gaz.sfgoth.com> X-Mailer: Sylpheed version 0.9.2 (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: 494 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, 3 Oct 2003 01:48:47 -0700 Mitchell Blank Jr wrote: > David S. Miller wrote: > > Doesn't work as-is. You'd have to not only store the timestamp and > > the cpu it was stored on, but also cross-call to that cpu to compute > > the correct timeval. > > That's definately the worst case. You could have each CPU periodically > store its current {tsc,timeval} tuple in a per-cpu location and extrapolate > from that. Right, that would work. There is the weird issue (with both the sparc64 example and your's here) of whether we should care about what happens when settimeofday() occurs. We probably shouldn't worry about it... as it gives weird results even currently. > It all depends on what percentage of skb's have ->stamp computed on a > CPU different from the one they came it on. For the common users of > ->stamp won't they have stayed on the same CPU? The worst case of > doing a cross-cpu-call should only happen relatively rarely. No, they typically won't. The packet comes in on cpu X, we stamp it on X, and we do a wakeup of tcpdump which will typically get scheduled first onto some other processor before X is done processing incoming packets. The higher the packet load the more likely this will happen. But forget this, as your dual tsc+timeval recording idea would work well and doesn't need a cross-cpu call. Although we'd need to think about how costly the cacheline activity is going to be with your idea compared to the seqlocked accesses to xtime. This is mainly a product of how often you intend to update the tsc+timeval thingy. From mitch@sfgoth.com Fri Oct 3 02:17:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 02:17:53 -0700 (PDT) Received: from gaz.sfgoth.com ([63.205.85.133]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h939HH25007993 for ; Fri, 3 Oct 2003 02:17:17 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.9p1/8.12.9) with ESMTP id h939QH16055146; Fri, 3 Oct 2003 02:26:18 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.9p1/8.12.6/Submit) id h939QH8k055145; Fri, 3 Oct 2003 02:26:17 -0700 (PDT) (envelope-from mitch) Date: Fri, 3 Oct 2003 02:26:17 -0700 From: Mitchell Blank Jr To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: do_gettimeofday Message-ID: <20031003092617.GI42593@gaz.sfgoth.com> References: <3F7C6F3B.6070502@sgi.com> <20031002125625.72b8c0a7.shemminger@osdl.org> <20031003004133.3148c39a.davem@redhat.com> <20031003082642.GF42593@gaz.sfgoth.com> <20031003012754.23de3f66.davem@redhat.com> <20031003084847.GH42593@gaz.sfgoth.com> <20031003015220.7ee6e451.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031003015220.7ee6e451.davem@redhat.com> User-Agent: Mutt/1.4.1i X-archive-position: 495 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev David S. Miller wrote: > There is the weird issue (with both the sparc64 example and your's > here) of whether we should care about what happens when settimeofday() > occurs. We probably shouldn't worry about it... as it gives weird > results even currently. Nah. If anything you'll get better results since you're computing the timeval later. This is another argument for caching the computation though - otherwise a settimeofday() could cause the packet timestamp to change drasically from one observation to the next :-) > > The worst case of > > doing a cross-cpu-call should only happen relatively rarely. > > No, they typically won't. The packet comes in on cpu X, we stamp > it on X, and we do a wakeup of tcpdump which will typically get > scheduled first onto some other processor before X is done processing > incoming packets. The higher the packet load the more likely this will > happen. I was more thinking about the other timestamp users. I don't consider tcpdump something that needs as much optimization. If we really wanted to we could have set a per-interface flag that says "someone will want the timestamp so compute it in the bh while we're still on the same processor" But see below - there probably isn't much cost anyways... > This is mainly a product > of how often you intend to update the tsc+timeval thingy. You could compute it relatively frequently and then only actually copy it to the hot cacheline if its diverged significantly from whats there. This would make the writes almost never happen (maybe once a minute) -Mitch From davem@pizda.ninka.net Fri Oct 3 02:27:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 02:28:31 -0700 (PDT) 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 h939Rw25009594 for ; Fri, 3 Oct 2003 02:27:59 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id CAA22858; Fri, 3 Oct 2003 02:23:38 -0700 Date: Fri, 3 Oct 2003 02:23:38 -0700 From: "David S. Miller" To: Mitchell Blank Jr Cc: netdev@oss.sgi.com Subject: Re: do_gettimeofday Message-Id: <20031003022338.6ffed45d.davem@redhat.com> In-Reply-To: <20031003092617.GI42593@gaz.sfgoth.com> References: <3F7C6F3B.6070502@sgi.com> <20031002125625.72b8c0a7.shemminger@osdl.org> <20031003004133.3148c39a.davem@redhat.com> <20031003082642.GF42593@gaz.sfgoth.com> <20031003012754.23de3f66.davem@redhat.com> <20031003084847.GH42593@gaz.sfgoth.com> <20031003015220.7ee6e451.davem@redhat.com> <20031003092617.GI42593@gaz.sfgoth.com> X-Mailer: Sylpheed version 0.9.2 (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: 496 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, 3 Oct 2003 02:26:17 -0700 Mitchell Blank Jr wrote: > I was more thinking about the other timestamp users. I don't consider > tcpdump something that needs as much optimization. Well, it's is the fact that usage of the timestamp is rare which we're trying to take advantage of. The whole idea is that fast_timestamp_to_timeval() can be a bit slow or suboptimal in order to make store_fast_timestamp() a lot faster or access less shared or locked state. From davem@pizda.ninka.net Fri Oct 3 02:52:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 02:53:07 -0700 (PDT) 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 h939qQ25013731 for ; Fri, 3 Oct 2003 02:52:27 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id CAA22927; Fri, 3 Oct 2003 02:48:05 -0700 Date: Fri, 3 Oct 2003 02:48:05 -0700 From: "David S. Miller" To: Sridhar Samudrala Cc: netdev@oss.sgi.com Subject: Re: [BK PATCH] 2.6 SCTP updates. Message-Id: <20031003024805.5bd85a56.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (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: 497 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, 2 Oct 2003 16:46:06 -0700 (PDT) Sridhar Samudrala wrote: > Please do a > bk pull http://linux-lksctp.bkbits.net/lksctp-2.5 > to get the following udpates to SCTP on top of linux 2.6.0-test6 > > The changesets include fixes for a couple of arch specific issues with ppc64 > and parisc64, few ADDIP extension related patches and a bug fix. Pulled, thanks a lot Sridhar. From ookhoi@humilis.net Fri Oct 3 03:30:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 03:30:58 -0700 (PDT) Received: from favonius.humilis.net (ookhoi.xs4all.nl [213.84.114.66]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h93AUL25015452 for ; Fri, 3 Oct 2003 03:30:22 -0700 Received: by favonius.humilis.net (Postfix, from userid 1000) id 29F53AFF81; Fri, 3 Oct 2003 12:30:25 +0200 (CEST) Date: Fri, 3 Oct 2003 12:30:25 +0200 From: Ookhoi To: Florian Zwoch Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: e1000 -> 82540EM on linux 2.6.0-test[45] very slow in one direction Message-ID: <20031003103025.GA20676@favonius> Reply-To: ookhoi@humilis.net References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: X-Uptime: 10:31:59 up 116 days, 9:57, 36 users, load average: 2.21, 1.96, 1.94 User-Agent: Mutt/1.5.4i X-archive-position: 498 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ookhoi@humilis.net Precedence: bulk X-list: netdev --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Florian and others, Florian Zwoch wrote (ao): > issue seems to partly solved. the e1000 driver seems to be ok! > i reconfigured my kernel and intentionally left out netfilter options. > after that my network performance was back to normal. > > netfilter was only compiled in the kernel. it was not used with any rules! > > so my wild guess would be that something with the netfilter code (i am > not 100% sure it was netfilter.. _maybe_ it was some small odd kernel > option i accidently enabled/disabled) is broken since test3 (again > uncertified. but i firstly noticed this switching from test3 to test4). I have the same problem with a dual port gigabit intel nic. Download is very fast, upload around 40k/sec. Kernel is 2.6.0-test6 Nic is dual port gigabit intel 82546EB The nic is connected to a 100Mbit switch, only one port in use. If I do 'ethtool -A eth0 tx on' the machine is offline for 50 seconds. When it is back online the upload is fast for a few seconds, and then returns to its old speed. Full 'ethtool -d eth0' output below. I have netfilter enabled, and will try another -test6 kernel with netfilter not compiled in to see if that indeed makes a difference. Btw, I had to compile the e1000 driver as a module. Compiled in it doesn't work, as is stated on the intel support page: http://www.intel.com/support/network/adapter/1000/linux/e1000.htm " This driver is only supported as a loadable module at this time. Intel is not supplying patches against the kernel source to allow for static linking of the driver." This is not clear from the kernel config help. A patch against 2.6.0-test6 is attached (I don't know how to only give n/m as an option). Btw2, can somebody please explain what the option E1000_NAPI does? " Use Rx Polling (NAPI) (E1000_NAPI) [N/y] (NEW) ? Sorry, no help available for this option yet. " Thanks in advance. ethtool -d eth0 gives: MAC Registers ------------- 0x00000: CTRL (Device control register) 0x08F00249 Duplex: full Endian mode (buffers): little Link reset: reset Set link up: 1 Invert Loss-Of-Signal: no Receive flow control: enabled Transmit flow control: disabled VLAN mode: disabled Auto speed detect: disabled Speed select: 1000Mb/s Force speed: no Force duplex: no 0x00008: STATUS (Device status register) 0x0000BB43 Duplex: full Link up: link config TBI mode: disabled Link speed: 100Mb/s Bus type: PCI-X Bus speed: 133MHz Bus width: 64-bit 0x00100: RCTL (Receive control register) 0x00008002 Receiver: enabled Store bad packets: disabled Unicast promiscuous: disabled Multicast promiscuous: disabled Long packet: disabled Descriptor minimum threshold size: 1/2 Broadcast accept mode: accept VLAN filter: disabled Cononical form indicator: disabled Discard pause frames: filtered Pass MAC control frames: don't pass Receive buffer size: 2048 0x02808: RDLEN (Receive desc length) 0x00001000 0x02810: RDH (Receive desc head) 0x00000014 0x02818: RDT (Receive desc tail) 0x00000010 0x02820: RDTR (Receive delay timer) 0x00000000 0x00400: TCTL (Transmit ctrl register) 0x0004010A Transmitter: enabled Pad short packets: enabled Software XOFF Transmission: disabled Re-transmit on late collision: disabled 0x03808: TDLEN (Transmit desc length) 0x00001000 0x03810: TDH (Transmit desc head) 0x000000DC 0x03818: TDT (Transmit desc tail) 0x000000DC 0x03820: TIDV (Transmit delay timer) 0x00000040 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="e1000-help-patch.diff" --- drivers/net/Kconfig.orig 2003-10-03 12:17:48.000000000 +0200 +++ drivers/net/Kconfig 2003-10-03 12:27:56.000000000 +0200 @@ -1876,9 +1876,12 @@ More specific information on configuring the driver is in . - To compile this driver as a module, choose M here and read - . The module - will be called e1000. + This driver is only supported as a loadable module at this + time. Intel is not supplying patches against the kernel source + to allow for static linking of the driver. + + Read . The + module will be called e1000. config E1000_NAPI bool "Use Rx Polling (NAPI)" --3MwIy2ne0vdjdPXF-- From hadi@cyberus.ca Fri Oct 3 04:09:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 04:10:28 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h93B9r25016898 for ; Fri, 3 Oct 2003 04:09:54 -0700 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.12) id 1A5Nol-000G2V-00; Fri, 03 Oct 2003 07:09:51 -0400 Subject: Re: [RFC] [PATCH 1/3] netpoll api From: jamal Reply-To: hadi@cyberus.ca To: Matt Mackall Cc: netdev@oss.sgi.com, Andrew Morton , Jeff Garzik In-Reply-To: <20031003014104.GR1897@waste.org> References: <20031003014104.GR1897@waste.org> Content-Type: text/plain Organization: jamalopolis Message-Id: <1065179359.1031.42.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Oct 2003 07:09:20 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 499 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 Thu, 2003-10-02 at 21:41, Matt Mackall wrote: > This patch implements a new netpoll API, which allows sending and > receiving packets in context where interrupts may be disabled. It > provides a common API for implementing features like netconsole, > netdump/LKCD, and kgdb-over-ethernet and manages to isolate them > almost completely from the details of the network layer. > Nice. Is the ethernet card in a case like this almost dedicated for this kind of work? Is disable_irq() in the controller safe for shared irqs? Or maybe this is critical enough that you dont care? Its a little wasteful to call the controller when there are is no work to be done; we have found in NAPI that any extra PCI transactions cost. (some IBM people doing benchmarking have complained about specweb not looking good where NAPI will have one extra PCI transaction per packet. You do it twice the rate NAPI would do it at low speeds). Again, the answer maybe who cares, this is critical work. Have you done any measurements to check whether it was worthwile to do the skb preallocation? cheers, jamal From yasuyuki.kozakai@toshiba.co.jp Fri Oct 3 04:21:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 04:22:08 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h93BLX25020146 for ; Fri, 3 Oct 2003 04:21:34 -0700 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id h93BJAF1024693; Fri, 3 Oct 2003 20:19:10 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id h93BJAPr009093; Fri, 3 Oct 2003 20:19:10 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id WAA09089 ; Fri, 3 Oct 2003 20:19:10 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id UAA18460; Fri, 3 Oct 2003 20:19:09 +0900 (JST) Received: by toshiba.co.jp id UAA11088; Fri, 3 Oct 2003 20:19:08 +0900 (JST) Date: Fri, 03 Oct 2003 20:19:07 +0900 (JST) Message-Id: <200310031119.UAA11088@toshiba.co.jp> To: laforge@netfilter.org Cc: yasuyuki.kozakai@toshiba.co.jp, coreteam@netfilter.org, netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [Patch]: IPv6 Connection Tracking From: Yasuyuki Kozakai In-Reply-To: <20030925092806.GC5758@sunbeam.de.gnumonks.org> References: <200309250521.OAA29293@toshiba.co.jp> <20030925092806.GC5758@sunbeam.de.gnumonks.org> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 500 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yasuyuki.kozakai@toshiba.co.jp Precedence: bulk X-list: netdev Hi, Harald, Sorry for the late reply. From: Harald Welte Date: Thu, 25 Sep 2003 11:28:06 +0200 > To summarize, I see the following options: > > 1) submit ip6_conntrack to the 2.6.x kernel > We would then need somebody committe to maintaining it, assuring > it keeps in sync with the work done on ip_conntrack. I do not want > to put the burden of ip_conntrack / ip6_conntrack synchronization on > everybody who submits patches/bugfixes/... > > 2) keep ip6_conntrack in patch-o-matic and start work on a l3 > independent conntrack system. > This would give more users to the code, since most advanced > netfilter users are using patch-o-matic anyway. I select 2), too. Harald, Could you add my patch to patch-o-matic ? Regards, ---------------------------------------- Yasuyuki KOZAKAI Communication Platform Laboratory, Corporate Research & Development Center, Toshiba Corporation yasuyuki.kozakai@toshiba.co.jp ---------------------------------------- From modica@sgi.com Fri Oct 3 05:09:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 05:09:57 -0700 (PDT) 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 h93C9K25020976 for ; Fri, 3 Oct 2003 05:09:20 -0700 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 h93C9Fq0007918 for ; Fri, 3 Oct 2003 05:09:15 -0700 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 h93C9Ecc11932428 for ; Fri, 3 Oct 2003 07:09:14 -0500 (CDT) Received: from sgi.com (cf-vpn-sw-corp-64-11.corp.sgi.com [134.15.64.11]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h93C9ERn233151279 for ; Fri, 3 Oct 2003 07:09:14 -0500 (CDT) Message-ID: <3F7D675D.4000905@sgi.com> Date: Fri, 03 Oct 2003 07:11:09 -0500 From: Steve Modica User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Linking interfaces to slots Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 501 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, If one wanted to figure out which ethX was in which PCI slot on which bus, what would be the most acceptable mechanism? The drivers have access to all this info, but then each driver would need some ioctl added. Is there some more generic place in the kernel that could be modified such that /proc/net/dev could hold this information? Steve From ookhoi@humilis.net Fri Oct 3 05:23:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 05:24:11 -0700 (PDT) Received: from favonius.humilis.net (ookhoi.xs4all.nl [213.84.114.66]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h93CNU25021469 for ; Fri, 3 Oct 2003 05:23:32 -0700 Received: by favonius.humilis.net (Postfix, from userid 1000) id 5715993514; Fri, 3 Oct 2003 14:23:29 +0200 (CEST) Date: Fri, 3 Oct 2003 14:23:29 +0200 From: Ookhoi To: Ookhoi Cc: Florian Zwoch , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: e1000 -> 82540EM on linux 2.6.0-test[45] very slow in one direction Message-ID: <20031003122329.GA21532@favonius> Reply-To: ookhoi@humilis.net References: <20031003103025.GA20676@favonius> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031003103025.GA20676@favonius> X-Uptime: 12:41:52 up 116 days, 12:08, 38 users, load average: 1.00, 1.00, 1.00 User-Agent: Mutt/1.5.4i X-archive-position: 502 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ookhoi@humilis.net Precedence: bulk X-list: netdev Ookhoi wrote (ao): > Florian Zwoch wrote (ao): > > issue seems to partly solved. the e1000 driver seems to be ok! > > i reconfigured my kernel and intentionally left out netfilter options. > > after that my network performance was back to normal. > > > > netfilter was only compiled in the kernel. it was not used with any rules! > > > > so my wild guess would be that something with the netfilter code (i am > > not 100% sure it was netfilter.. _maybe_ it was some small odd kernel > > option i accidently enabled/disabled) is broken since test3 (again > > uncertified. but i firstly noticed this switching from test3 to test4). > I have netfilter enabled, and will try another -test6 kernel with > netfilter not compiled in to see if that indeed makes a difference. I can confirm now that disabling netfilter in 2.6.0-test6 makes the nic perform oke wrt upload. I (just like Florian) had no iptables rules active in the former 2.6.0-test6 kernel, but netfilter was compiled in. From david-b@pacbell.net Fri Oct 3 06:30:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 06:31:25 -0700 (PDT) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h93DUm25022513 for ; Fri, 3 Oct 2003 06:30:48 -0700 Received: from pacbell.net (ppp-67-118-247-247.dialup.pltn13.pacbell.net [67.118.247.247]) by mta7.pltn13.pbi.net (8.12.9/8.12.3) with ESMTP id h93DUl1R018123; Fri, 3 Oct 2003 06:30:47 -0700 (PDT) Message-ID: <3F7D7B89.7090406@pacbell.net> Date: Fri, 03 Oct 2003 06:37:13 -0700 From: David Brownell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Steve Modica CC: netdev@oss.sgi.com Subject: Re: Linking interfaces to slots References: <3F7D675D.4000905@sgi.com> In-Reply-To: <3F7D675D.4000905@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 503 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david-b@pacbell.net Precedence: bulk X-list: netdev Steve Modica wrote: > > If one wanted to figure out which ethX was in which PCI slot on which > bus, what would be the most acceptable mechanism? The drivers have > access to all this info, but then each driver would need some ioctl > added. Is there some more generic place in the kernel that could be > modified such that /proc/net/dev could hold this information? On 2.6 there's /sys/class/net/ethX/device, and ethtool_drvinfo.bus_info support should exist too... - Dave From lxie@us.ibm.com Fri Oct 3 06:39:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 06:40:26 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h93Ddr25022936; Fri, 3 Oct 2003 06:39:54 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id h93Ddl67226034; Fri, 3 Oct 2003 09:39:47 -0400 Received: from d03nm691.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h93DdkBq164232; Fri, 3 Oct 2003 07:39:47 -0600 Subject: Re: Linking interfaces to slots To: Steve Modica Cc: netdev@oss.sgi.com, netdev-bounce@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Linda Xie Date: Fri, 3 Oct 2003 08:39:44 -0500 X-MIMETrack: Serialize by Router on D03NM691/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/03/2003 07:39:46 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-archive-position: 504 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lxie@us.ibm.com Precedence: bulk X-list: netdev Those information can be obtained by ls -l /sys/class/net/ethX. Here is a example: bigboylp4:/home/linda # ls -l /sys/class/net/eth* /sys/class/net/eth0: total 0 drwxr-xr-x 3 root root 0 2003-10-02 18:52 . drwxr-xr-x 6 root root 0 2003-10-02 18:52 .. -r--r--r-- 1 root root 4096 2003-10-02 18:52 addr_len -r--r--r-- 1 root root 4096 2003-10-02 18:52 address -r--r--r-- 1 root root 4096 2003-10-02 18:52 broadcast lrwxrwxrwx 1 root root 53 2003-10-02 18:52 device -> ../../../devices/pci0005:00/0005:00:0b.2/0005:21:01.0 <-- pci dev lrwxrwxrwx 1 root root 29 2003-10-02 18:52 driver -> ../../../bus/pci/drivers/e100 -r--r--r-- 1 root root 4096 2003-10-02 18:52 features -rw-r--r-- 1 root root 4096 2003-10-02 18:52 flags -r--r--r-- 1 root root 4096 2003-10-02 18:52 ifindex -r--r--r-- 1 root root 4096 2003-10-02 18:52 iflink -rw-r--r-- 1 root root 4096 2003-10-02 18:52 mtu drwxr-xr-x 2 root root 0 2003-10-02 18:52 statistics -rw-r--r-- 1 root root 4096 2003-10-02 18:52 tx_queue_len -r--r--r-- 1 root root 4096 2003-10-02 18:52 type /sys/class/net/eth1: total 0 drwxr-xr-x 3 root root 0 2003-10-02 19:51 . drwxr-xr-x 6 root root 0 2003-10-02 18:52 .. -r--r--r-- 1 root root 4096 2003-10-02 19:51 addr_len -r--r--r-- 1 root root 4096 2003-10-02 19:51 address -r--r--r-- 1 root root 4096 2003-10-02 19:51 broadcast lrwxrwxrwx 1 root root 53 2003-10-02 19:51 device -> ../../../devices/pci0005:00/0005:00:0b.6/0005:61:01.0 <-- pci dev lrwxrwxrwx 1 root root 29 2003-10-02 19:51 driver -> ../../../bus/pci/drivers/e100 -r--r--r-- 1 root root 4096 2003-10-02 19:51 features -rw-r--r-- 1 root root 4096 2003-10-02 19:51 flags -r--r--r-- 1 root root 4096 2003-10-02 19:51 ifindex -r--r--r-- 1 root root 4096 2003-10-02 19:51 iflink -rw-r--r-- 1 root root 4096 2003-10-02 19:51 mtu drwxr-xr-x 2 root root 0 2003-10-02 19:51 statistics -rw-r--r-- 1 root root 4096 2003-10-02 19:51 tx_queue_len -r--r--r-- 1 root root 4096 2003-10-02 19:51 type bigboylp4:/home/linda # There are two ethernet adapters, eth0 and eth1, in the system. In PCI world, eth0 is 0005:21:01.0 and eth1 is pci_dev 0005:61:01.0. A shell script can be used for greping ethX info, then parsing the info and generating a nice formatted output. Linda From davem@pizda.ninka.net Fri Oct 3 07:00:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 07:00:49 -0700 (PDT) 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 h93E0F25023494 for ; Fri, 3 Oct 2003 07:00:16 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id GAA23902; Fri, 3 Oct 2003 06:55:52 -0700 Date: Fri, 3 Oct 2003 06:55:52 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jt@bougret.hpl.hp.com, irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (1/11) Irda dongle module owner support Message-Id: <20031003065552.6b734105.davem@redhat.com> In-Reply-To: <20031002152026.4bfd2c67.shemminger@osdl.org> References: <20031002152026.4bfd2c67.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (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: 505 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 Jean noted some problems he has with these changes, in particular the hashbin locking bits. So I'm going to wait until that stuff is resolved since all the other IRDA patches in this series depend upon this first dongle module owner infrastructure one. Or did I misinterpret what happened? From davem@pizda.ninka.net Fri Oct 3 07:02:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 07:03:21 -0700 (PDT) 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 h93E2l25023846 for ; Fri, 3 Oct 2003 07:02:47 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id GAA23922; Fri, 3 Oct 2003 06:58:24 -0700 Date: Fri, 3 Oct 2003 06:58:24 -0700 From: "David S. Miller" To: Mitchell Blank Jr Cc: chas3@users.sourceforge.net, chas@cmf.nrl.navy.mil, netdev@oss.sgi.com Subject: Re: [RFC] add rtnl semaphore to linux-atm Message-Id: <20031003065824.713627c6.davem@redhat.com> In-Reply-To: <20031003022615.GA42593@gaz.sfgoth.com> References: <200310011134.h91BYPkT003172@ginger.cmf.nrl.navy.mil> <20031001054226.126cea7b.davem@redhat.com> <20031003022615.GA42593@gaz.sfgoth.com> X-Mailer: Sylpheed version 0.9.2 (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: 506 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, 2 Oct 2003 19:26:15 -0700 Mitchell Blank Jr wrote: > My personal recommendations: > * There should be a per-atm-device semaphore held across calls into the > driver's ->open, ->close, ->change_qos and maybe a couple other things > to serialize those operations (for the sake of keeping the drivers > sane - there's no reason there should be multiple operations pending) Ok, but what Chas is trying to do is move the ATM device stuff over to a model that makes use of the existing network device infrastructure for solving these kinds of problems. Part of that is using the rtnl semaphore etc. I would rather Chas use the rtnl semaphore for synchronization than to ultra-optimize this code by using the rwlock as I had suggested to him. From Robert.Olsson@data.slu.se Fri Oct 3 07:10:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 07:11:15 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h93EAd25024344 for ; Fri, 3 Oct 2003 07:10:40 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.9.3+/8.9.3) with ESMTP id QAA29078; Fri, 3 Oct 2003 16:10:32 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 8E771EC22F; Fri, 3 Oct 2003 16:10:33 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16253.33625.541433.36206@robur.slu.se> Date: Fri, 3 Oct 2003 16:10:33 +0200 To: Jeff Garzik Cc: Robert Olsson , Andrew Morton , netdev@oss.sgi.com, dfages@arkoon.net Subject: Re: Fw: [BUG/PATCH] CONFIG_NET_HW_FLOWCONTROL and SMP In-Reply-To: <3F7C64BC.7030701@pobox.com> References: <20030929123734.5bd97a47.akpm@osdl.org> <16248.41796.797321.700866@robur.slu.se> <3F78A691.1040406@pobox.com> <16252.17618.866515.952549@robur.slu.se> <3F7C64BC.7030701@pobox.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-archive-position: 507 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Jeff Garzik writes: > > Looks great to me. I'll give it some testing here, and 99% likely will > apply it. > > Andrew, would you be willing to merge this into -mm for some > simultaneous netwide testing? Fine! Here is a additional patch to active disable poll so we don't have to wait in dev_close() for traffic to disappear. Cheers. --ro --- drivers/net/tulip/interrupt.c.03103 2001-11-03 18:52:54.000000000 +0100 +++ drivers/net/tulip/interrupt.c 2003-10-03 13:21:46.000000000 +0200 @@ -116,6 +116,8 @@ tp->stats_poll_starts++; #endif + if(!netif_running(dev)) goto done; + if (rx_work_limit > dev->quota) rx_work_limit = dev->quota; @@ -241,7 +243,7 @@ * finally: amount of IO did not increase at all. */ } while ((inl(dev->base_addr + CSR5) & RxIntr)); -/* done: */ +done: #ifdef USE_MITIGATION From davem@pizda.ninka.net Fri Oct 3 07:35:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 07:35:44 -0700 (PDT) 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 h93EZB25024954 for ; Fri, 3 Oct 2003 07:35:11 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id HAA24087; Fri, 3 Oct 2003 07:30:40 -0700 Date: Fri, 3 Oct 2003 07:30:39 -0700 From: "David S. Miller" To: Julian Anastasov Cc: netdev@oss.sgi.com Subject: Re: tunnel xmit and h.raw Message-Id: <20031003073039.7ca1a76c.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (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: 508 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, 3 Oct 2003 03:00:27 +0300 (EEST) Julian Anastasov wrote: > Is the following change needed? May be yes for all kernels > where the nearest skb_shared checks are actual. There seems to be no end to these kinds of bugs in the tunnel drivers! Didn't we fix a nearly identical set of bugs in the tunnel drivers just a month or two ago? I'll review this some more tomorrow and unless I find some problem I'll apply your patch. Thanks a lot. From ja@ssi.bg Fri Oct 3 07:57:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 07:57:45 -0700 (PDT) Received: from l.himel.bg (IDENT:root@unamed.infotel.bg [212.39.68.18] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h93Ev725026147 for ; Fri, 3 Oct 2003 07:57:09 -0700 Received: from linux.himel.bg (IDENT:ja@linux.himel.bg [127.0.0.1]) by l.himel.bg (8.11.6/8.9.3) with ESMTP id h93EuZY13146; Fri, 3 Oct 2003 17:56:35 +0300 Date: Fri, 3 Oct 2003 17:56:35 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@l To: "David S. Miller" cc: netdev@oss.sgi.com Subject: Re: tunnel xmit and h.raw In-Reply-To: <20031003073039.7ca1a76c.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 509 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 Hello, On Fri, 3 Oct 2003, David S. Miller wrote: > > Is the following change needed? May be yes for all kernels > > where the nearest skb_shared checks are actual. > > There seems to be no end to these kinds of bugs in the tunnel > drivers! > > Didn't we fix a nearly identical set of bugs in the tunnel > drivers just a month or two ago? The same place, but this one is special: h.raw is updated for us on reallocation but if the skb is shared I do not know if this is fatal for the other skb users, we change also their h.raw. But I rely on your opinion, may be it is safer with this change. > I'll review this some more tomorrow and unless I find some problem > I'll apply your patch. Thanks a lot. Regards -- Julian Anastasov From davem@pizda.ninka.net Fri Oct 3 08:09:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 08:09:57 -0700 (PDT) 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 h93F9H25026856 for ; Fri, 3 Oct 2003 08:09:18 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id IAA24271; Fri, 3 Oct 2003 08:04:44 -0700 Date: Fri, 3 Oct 2003 08:04:44 -0700 From: "David S. Miller" To: Julian Anastasov Cc: netdev@oss.sgi.com Subject: Re: tunnel xmit and h.raw Message-Id: <20031003080444.173a403c.davem@redhat.com> In-Reply-To: References: <20031003073039.7ca1a76c.davem@redhat.com> X-Mailer: Sylpheed version 0.9.2 (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: 510 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, 3 Oct 2003 17:56:35 +0300 (EEST) Julian Anastasov wrote: > On Fri, 3 Oct 2003, David S. Miller wrote: > > > Didn't we fix a nearly identical set of bugs in the tunnel > > drivers just a month or two ago? > > The same place, but this one is special: h.raw is updated > for us on reallocation but if the skb is shared I do not know if this is > fatal for the other skb users, we change also their h.raw. But I rely > on your opinion, may be it is safer with this change. Oh, I see, the code is actually not buggy as-is. The following two sequences are identical: 1) skb->h.raw = skb->nh.raw; new_skb = skb_realloc_headroom(...); skb = new_skb; 2) new_skb = skb_realloc_headroom(...); skb = new_skb; skb->h.raw = skb->nh.raw; Because skb_realloc_headroom() keeps all the skb->*.raw pointers in the right relative place if it allocates new data pointers or whatever. But the code is certainly clearer to read with your changes so I'll add them as a code cleanup instead of a bug fix :) From davem@pizda.ninka.net Fri Oct 3 08:10:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 08:10:55 -0700 (PDT) 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 h93FAM25026943 for ; Fri, 3 Oct 2003 08:10:22 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id IAA24277; Fri, 3 Oct 2003 08:05:43 -0700 Date: Fri, 3 Oct 2003 08:05:43 -0700 From: "David S. Miller" To: Julian Anastasov Cc: netdev@oss.sgi.com Subject: Re: tunnel xmit and h.raw Message-Id: <20031003080543.5d8e8d41.davem@redhat.com> In-Reply-To: References: <20031003073039.7ca1a76c.davem@redhat.com> X-Mailer: Sylpheed version 0.9.2 (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: 511 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, 3 Oct 2003 17:56:35 +0300 (EEST) Julian Anastasov wrote: > The same place, but this one is special: h.raw is updated > for us on reallocation but if the skb is shared I do not know if this is > fatal for the other skb users, we change also their h.raw. Sorry, replying again... I hadn't read your reply correctly. Indeed, I have to think about what changing skb->h.raw might do to other users, it might indeed be an issue. From mika.penttila@kolumbus.fi Fri Oct 3 08:42:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 08:43:14 -0700 (PDT) Received: from notes.hallinto.turkuamk.fi (notes.hallinto.turkuamk.fi [195.148.215.149]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h93Fgc25031383 for ; Fri, 3 Oct 2003 08:42:39 -0700 Received: from kolumbus.fi ([193.166.244.70]) by marconi.hallinto.turkuamk.fi (Lotus Domino Release 5.0.8) with ESMTP id 2003100318441262:30362 ; Fri, 3 Oct 2003 18:44:12 +0300 Message-ID: <3F7D9A87.3010005@kolumbus.fi> Date: Fri, 03 Oct 2003 18:49:27 +0300 From: =?ISO-8859-1?Q?Mika_Penttil=E4?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Anastasov CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: tunnel xmit and h.raw References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on marconi.hallinto.turkuamk.fi/TAMK(Release 5.0.8 |June 18, 2001) at 03.10.2003 18:44:12, Serialize by Router on notes.hallinto.turkuamk.fi/TAMK(Release 5.0.10 |March 22, 2002) at 03.10.2003 18:43:38, Serialize complete at 03.10.2003 18:43:38 Content-Type: multipart/alternative; boundary="------------030205090500090605040302" X-archive-position: 512 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.penttila@kolumbus.fi Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------030205090500090605040302 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed If skb is shared skb_realloc_headroom() makes a private head, so no problem here. Actually the skb_cloned() test seems redundant in this context. --Mika Julian Anastasov wrote: > Hello, > >On Fri, 3 Oct 2003, David S. Miller wrote: > > > >>> Is the following change needed? May be yes for all kernels >>>where the nearest skb_shared checks are actual. >>> >>> >>There seems to be no end to these kinds of bugs in the tunnel >>drivers! >> >>Didn't we fix a nearly identical set of bugs in the tunnel >>drivers just a month or two ago? >> >> > > The same place, but this one is special: h.raw is updated >for us on reallocation but if the skb is shared I do not know if this is >fatal for the other skb users, we change also their h.raw. But I rely >on your opinion, may be it is safer with this change. > > > >>I'll review this some more tomorrow and unless I find some problem >>I'll apply your patch. Thanks a lot. >> >> > >Regards > >-- >Julian Anastasov > > > > > --------------030205090500090605040302 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii If skb is shared skb_realloc_headroom() makes a private head, so no problem here. Actually the skb_cloned() test seems redundant in this context.

--Mika


Julian Anastasov wrote:
	Hello,

On Fri, 3 Oct 2003, David S. Miller wrote:

  
	Is the following change needed? May be yes for all kernels
where the nearest skb_shared checks are actual.
      
There seems to be no end to these kinds of bugs in the tunnel
drivers!

Didn't we fix a nearly identical set of bugs in the tunnel
drivers just a month or two ago?
    

	The same place, but this one is special: h.raw is updated
for us on reallocation but if the skb is shared I do not know if this is
fatal for the other skb users, we change also their h.raw. But I rely
on your opinion, may be it is safer with this change.

  
I'll review this some more tomorrow and unless I find some problem
I'll apply your patch.  Thanks a lot.
    

Regards

--
Julian Anastasov <ja@ssi.bg>
--------------030205090500090605040302-- From greearb@candelatech.com Fri Oct 3 09:42:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 09:43:07 -0700 (PDT) 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 h93GgT25003620 for ; Fri, 3 Oct 2003 09:42:31 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h93GgLUG031006; Fri, 3 Oct 2003 09:42:21 -0700 Message-ID: <3F7DA6EB.4040200@candelatech.com> Date: Fri, 03 Oct 2003 09:42:19 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mitchell Blank Jr CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: do_gettimeofday References: <3F7C6F3B.6070502@sgi.com> <20031002125625.72b8c0a7.shemminger@osdl.org> <20031003004133.3148c39a.davem@redhat.com> <20031003082642.GF42593@gaz.sfgoth.com> <20031003012754.23de3f66.davem@redhat.com> <20031003084847.GH42593@gaz.sfgoth.com> <20031003015220.7ee6e451.davem@redhat.com> <20031003092617.GI42593@gaz.sfgoth.com> In-Reply-To: <20031003092617.GI42593@gaz.sfgoth.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 513 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 Mitchell Blank Jr wrote: > David S. Miller wrote: > >>There is the weird issue (with both the sparc64 example and your's >>here) of whether we should care about what happens when settimeofday() >>occurs. We probably shouldn't worry about it... as it gives weird >>results even currently. > > > Nah. If anything you'll get better results since you're computing > the timeval later. > > This is another argument for caching the computation though - otherwise > a settimeofday() could cause the packet timestamp to change drasically > from one observation to the next :-) It would also be nice to be able to set a flag on raw sockets to just have the 'raw' timestamp passed up to user-space. In many cases, the relative timestamp may be all that is needed, and user-space could optimize the conversion to gettimeofday as needed. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From shemminger@osdl.org Fri Oct 3 10:22:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 10:23:05 -0700 (PDT) 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 h93HMU25007957 for ; Fri, 3 Oct 2003 10:22:31 -0700 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 h93HLw121579; Fri, 3 Oct 2003 10:21:58 -0700 Date: Fri, 3 Oct 2003 10:21:33 -0700 From: Stephen Hemminger To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, "David S. Miller" , irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (1/11) Irda dongle module owner support (revised) Message-Id: <20031003102133.2e5a41a2.shemminger@osdl.org> In-Reply-To: <20031002233335.GA7945@bougret.hpl.hp.com> References: <20031002152026.4bfd2c67.shemminger@osdl.org> <20031002233335.GA7945@bougret.hpl.hp.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 514 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 Revised version of the dongle module owner patch, incorporating Jean's comments. This replaces the original patch. It provides an owner field an appropriate ref counting for IRDA dongles. Changes since list version: s/dongle_lock/dongles->hb_spinlock/ get lock on device_cleanup replace ASSERT() about in_interrupt with might_sleep(). In case your curious about locking, the callers are: module_init -> irda_device_init module_exit -> irda_device_cleanup irport_net_ioctl -> irda_device_dongle_init module_init -> XXX_dongle_init -> irda_device_register_dongle module_exit -> XXX_dongle_exit -> irda_device_unregister_dongle In other words, no interrupt or BH access to the dongle list. Obviously, hashing this list is overkill, but "when in Rome"... --- linux-2.5/net/irda/irda_device.c 2003-10-01 13:40:11.000000000 -0700 +++ irda-2.5/net/irda/irda_device.c 2003-10-03 10:03:52.497879915 -0700 @@ -85,7 +85,7 @@ static void irda_task_timer_expired(void int __init irda_device_init( void) { - dongles = hashbin_new(HB_LOCK); + dongles = hashbin_new(HB_NOLOCK); if (dongles == NULL) { printk(KERN_WARNING "IrDA: Can't allocate dongles hashbin!\n"); return -ENOMEM; @@ -109,7 +109,9 @@ void __exit irda_device_cleanup(void) IRDA_DEBUG(4, "%s()\n", __FUNCTION__); hashbin_delete(tasks, (FREE_FUNC) __irda_task_delete); + spin_lock(&dongles->hb_spinlock); hashbin_delete(dongles, NULL); + spin_unlock(&dongles->hb_spinlock); } /* @@ -424,25 +426,34 @@ int irda_device_txqueue_empty(struct net dongle_t *irda_device_dongle_init(struct net_device *dev, int type) { struct dongle_reg *reg; - dongle_t *dongle; + dongle_t *dongle = NULL; - ASSERT(dev != NULL, return NULL;); + might_sleep(); + + spin_lock(&dongles->hb_spinlock); + reg = hashbin_find(dongles, type, NULL); #ifdef CONFIG_KMOD - ASSERT(!in_interrupt(), return NULL;); /* Try to load the module needed */ - request_module("irda-dongle-%d", type); + if (!reg && capable(CAP_SYS_MODULE)) { + spin_unlock(&dongles->hb_spinlock); + + request_module("irda-dongle-%d", type); + + spin_lock(&dongles->hb_spinlock); + reg = hashbin_find(dongles, type, NULL); + } #endif - if (!(reg = hashbin_lock_find(dongles, type, NULL))) { - ERROR("IrDA: Unable to find requested dongle\n"); - return NULL; + if (!reg || !try_module_get(reg->owner) ) { + ERROR("IrDA: Unable to find requested dongle type %x\n", type); + goto out; } /* Allocate dongle info for this instance */ dongle = kmalloc(sizeof(dongle_t), GFP_KERNEL); if (!dongle) - return NULL; + goto out; memset(dongle, 0, sizeof(dongle_t)); @@ -450,6 +461,8 @@ dongle_t *irda_device_dongle_init(struct dongle->issue = reg; dongle->dev = dev; + out: + spin_unlock(&dongles->hb_spinlock); return dongle; } @@ -461,7 +474,7 @@ int irda_device_dongle_cleanup(dongle_t ASSERT(dongle != NULL, return -1;); dongle->issue->close(dongle); - + module_put(dongle->issue->owner); kfree(dongle); return 0; @@ -472,14 +485,16 @@ int irda_device_dongle_cleanup(dongle_t */ int irda_device_register_dongle(struct dongle_reg *new) { + spin_lock(&dongles->hb_spinlock); /* Check if this dongle has been registered before */ - if (hashbin_lock_find(dongles, new->type, NULL)) { - MESSAGE("%s: Dongle already registered\n", __FUNCTION__); - return 0; - } - - /* Insert IrDA dongle into hashbin */ - hashbin_insert(dongles, (irda_queue_t *) new, new->type, NULL); + if (hashbin_find(dongles, new->type, NULL)) { + MESSAGE("%s: Dongle type %x already registered\n", + __FUNCTION__, new->type); + } else { + /* Insert IrDA dongle into hashbin */ + hashbin_insert(dongles, (irda_queue_t *) new, new->type, NULL); + } + spin_unlock(&dongles->hb_spinlock); return 0; } @@ -494,11 +509,11 @@ void irda_device_unregister_dongle(struc { struct dongle *node; + spin_lock(&dongles->hb_spinlock); node = hashbin_remove(dongles, dongle->type, NULL); - if (!node) { + if (!node) ERROR("%s: dongle not found!\n", __FUNCTION__); - return; - } + spin_unlock(&dongles->hb_spinlock); } /* From jt@bougret.hpl.hp.com Fri Oct 3 10:31:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 10:32:06 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h93HVW25008900 for ; Fri, 3 Oct 2003 10:31:32 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id 303091C02334; Fri, 3 Oct 2003 10:31:32 -0700 (PDT) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_28810)/8.9.3 HPLabs Timeshare Server) with ESMTP id KAA04053; Fri, 3 Oct 2003 10:31:31 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1A5Tm7-0003lN-00; Fri, 03 Oct 2003 10:31:31 -0700 Date: Fri, 3 Oct 2003 10:31:31 -0700 To: Stephen Hemminger Cc: "David S. Miller" , irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (1/11) Irda dongle module owner support (revised) Message-ID: <20031003173131.GB14313@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20031002152026.4bfd2c67.shemminger@osdl.org> <20031002233335.GA7945@bougret.hpl.hp.com> <20031003102133.2e5a41a2.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031003102133.2e5a41a2.shemminger@osdl.org> 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: 515 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 Fri, Oct 03, 2003 at 10:21:33AM -0700, Stephen Hemminger wrote: > Revised version of the dongle module owner patch, incorporating Jean's comments. > This replaces the original patch. It provides an owner field an appropriate > ref counting for IRDA dongles. > > Changes since list version: > s/dongle_lock/dongles->hb_spinlock/ > get lock on device_cleanup > replace ASSERT() about in_interrupt with might_sleep(). Perfect ! Thanks for the quick turnaround, and sorry for the extra work. > In case your curious about locking, the callers are: > module_init -> irda_device_init > module_exit -> irda_device_cleanup > irport_net_ioctl -> irda_device_dongle_init > module_init -> XXX_dongle_init -> irda_device_register_dongle > module_exit -> XXX_dongle_exit -> irda_device_unregister_dongle > > In other words, no interrupt or BH access to the dongle list. > Obviously, hashing this list is overkill, Ok. > but "when in Rome"... Eat some pasta ? Maintaining others people code is very much like archeological excavation, sometimes you find treasures buried in the various stratas, but most of the time... Have fun... Jean From christopher.leech@intel.com Fri Oct 3 11:27:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 11:28:15 -0700 (PDT) Received: from hermes.py.intel.com (hermes.py.intel.com [146.152.216.3]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h93IRc25013142 for ; Fri, 3 Oct 2003 11:27:39 -0700 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.11.6-20030918-01/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h93IMVR27296 for ; Fri, 3 Oct 2003 18:22:31 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.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 h93IQx408464 for ; Fri, 3 Oct 2003 18:26:59 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003100311273130087 ; Fri, 03 Oct 2003 11:27:31 -0700 Received: from orsmsx404.amr.corp.intel.com ([192.168.65.44]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 3 Oct 2003 11:27:30 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: e1000 -> 82540EM on linux 2.6.0-test[45] very slow in one direction Date: Fri, 3 Oct 2003 11:27:30 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: e1000 -> 82540EM on linux 2.6.0-test[45] very slow in one direction Thread-Index: AcOJmY73Di4fqm7+QR63OlqNHBtI+gAQBTMg From: "Leech, Christopher" To: Cc: , X-OriginalArrivalTime: 03 Oct 2003 18:27:30.0996 (UTC) FILETIME=[01A5CF40:01C389DC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h93IRc25013142 X-archive-position: 516 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christopher.leech@intel.com Precedence: bulk X-list: netdev > Btw, I had to compile the e1000 driver as a module. Compiled in it > doesn't work, as is stated on the intel support page: > This is not clear from the kernel config help. A patch against > 2.6.0-test6 is attached (I don't know how to only give n/m as an > option). This patch is not necessary or desired. The version of e1000 that ships with the kernel source should work fine statically linked, and the comment on the Intel support web page applies to the separate download of the e1000 source. If you download the driver source from Intel and do the work to add it into a kernel source tree yourself, Intel customer support may not help you when you have problems. If you are having problems compiling in the version of e1000 that ships with the kernel, please report it on netdev and we'll try and help. > Btw2, can somebody please explain what the option E1000_NAPI does? NAPI is a network driver polling mode interface. It enables a form of software managed interrupt moderation, and may result in better performance under some traffic patterns (specifically sustained high packet rate reception). -- Chris From shemminger@osdl.org Fri Oct 3 11:31:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 11:32:14 -0700 (PDT) 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 h93IVd25013741 for ; Fri, 3 Oct 2003 11:31:42 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h93IVW103727; Fri, 3 Oct 2003 11:31:32 -0700 Date: Fri, 3 Oct 2003 11:31:06 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] sbni -- get rid of check_region Message-Id: <20031003113106.45b21aa5.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 517 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 In sbni driver for 2.6.0-test6 Replace check_region with appropriate request_region, and make sure to do release_region as required in error unwinds. diff -Nru a/drivers/net/wan/sbni.c b/drivers/net/wan/sbni.c --- a/drivers/net/wan/sbni.c Fri Oct 3 11:27:51 2003 +++ b/drivers/net/wan/sbni.c Fri Oct 3 11:27:51 2003 @@ -292,7 +292,6 @@ != NULL ) { int pci_irq_line; unsigned long pci_ioaddr; - u16 subsys; if( pdev->vendor != SBNI_PCI_VENDOR && pdev->device != SBNI_PCI_DEVICE ) @@ -302,10 +301,13 @@ pci_irq_line = pdev->irq; /* Avoid already found cards from previous calls */ - if( !request_region( pci_ioaddr, SBNI_IO_EXTENT, dev->name ) ) { - pci_read_config_word( pdev, PCI_SUBSYSTEM_ID, &subsys ); + if( !request_region( pci_ioaddr, SBNI_IO_EXTENT, dev->name )) { + u16 subsys; + pci_read_config_word( pdev, PCI_SUBSYSTEM_ID, &subsys); + if( subsys != 2 || /* Dual adapter is present */ - check_region( pci_ioaddr += 4, SBNI_IO_EXTENT ) ) + !request_region(pci_ioaddr += 4, SBNI_IO_EXTENT, + dev->name) ) continue; } @@ -318,10 +320,15 @@ pci_irq_line ); /* avoiding re-enable dual adapters */ - if( (pci_ioaddr & 7) == 0 && pci_enable_device( pdev ) ) - return -EIO; - if( sbni_probe1( dev, pci_ioaddr, pci_irq_line ) ) + if( (pci_ioaddr & 7) == 0 && pci_enable_device( pdev ) ) { + release_region( pci_ioaddr, SBNI_IO_EXTENT); + return -EIO; + } + + else if( sbni_probe1( dev, pci_ioaddr, pci_irq_line ) ) return 0; + + release_region( pci_ioaddr, SBNI_IO_EXTENT); } return -ENODEV; } @@ -332,10 +339,8 @@ { struct net_local *nl; - if( sbni_card_probe( ioaddr ) ) { - release_region( ioaddr, SBNI_IO_EXTENT ); + if( sbni_card_probe( ioaddr ) ) return 0; - } outb( 0, ioaddr + CSR0 ); @@ -352,7 +357,6 @@ if( !irq ) { printk( KERN_ERR "%s: can't detect device irq!\n", dev->name ); - release_region( ioaddr, SBNI_IO_EXTENT ); return 0; } } else if( irq == 2 ) @@ -365,7 +369,6 @@ nl = dev->priv; if( !nl ) { printk( KERN_ERR "%s: unable to get memory!\n", dev->name ); - release_region( ioaddr, SBNI_IO_EXTENT ); return 0; } From shemminger@osdl.org Fri Oct 3 11:44:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 11:44:56 -0700 (PDT) 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 h93IiM25014914 for ; Fri, 3 Oct 2003 11:44:22 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h93IiE106710; Fri, 3 Oct 2003 11:44:14 -0700 Date: Fri, 3 Oct 2003 11:43:47 -0700 From: Stephen Hemminger To: Jeff Garzik , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [RFT] syncppp needs to pullup headers Message-Id: <20031003114347.31ee740b.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 518 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 In 2.6.0-test6 wan syncppp driver claims to be a "new" protocol and handle shared skb's but it needs to make sure data is contiguous before overlaying headers. It is not a serious problem because the sync drivers never generate nonlinear skbuff's anyway. Don't have hardware that uses this, so could someone please do a sanity test on this. diff -Nru a/drivers/net/wan/syncppp.c b/drivers/net/wan/syncppp.c --- a/drivers/net/wan/syncppp.c Fri Oct 3 11:28:11 2003 +++ b/drivers/net/wan/syncppp.c Fri Oct 3 11:28:11 2003 @@ -236,7 +236,7 @@ sp->ipkts++; } - if (skb->len <= PPP_HEADER_LEN) { + if (!pskb_may_pull(skb, PPP_HEADER_LEN)) { /* Too small packet, drop it. */ if (sp->pp_flags & PP_DEBUG) printk (KERN_DEBUG "%s: input packet is too small, %d bytes\n", @@ -473,7 +473,7 @@ u8 *p, opt[6]; u32 rmagic; - if (len < 4) { + if (!pskb_may_pull(skb, sizeof(struct lcp_header))) { if (sp->pp_flags & PP_DEBUG) printk (KERN_WARNING "%s: invalid lcp packet length: %d bytes\n", dev->name, len); @@ -707,7 +707,9 @@ struct cisco_packet *h; struct net_device *dev = sp->pp_if; - if (skb->len != CISCO_PACKET_LEN && skb->len != CISCO_BIG_PACKET_LEN) { + if (!pskb_may_pull(skb, sizeof(struct cisco_packet)) + || (skb->len != CISCO_PACKET_LEN + && skb->len != CISCO_BIG_PACKET_LEN)) { if (sp->pp_flags & PP_DEBUG) printk (KERN_WARNING "%s: invalid cisco packet length: %d bytes\n", dev->name, skb->len); @@ -1211,8 +1213,7 @@ struct net_device *dev = sp->pp_if; int len = skb->len; - if (len < 4) - { + if (!pskb_may_pull(skb, sizeof(struct lcp_header))) { if (sp->pp_flags & PP_DEBUG) printk (KERN_WARNING "%s: invalid ipcp packet length: %d bytes\n", dev->name, len); From oxymoron@waste.org Fri Oct 3 12:12:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 12:12:37 -0700 (PDT) Received: from waste.org (waste.org [209.173.204.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h93JBw25019968 for ; Fri, 3 Oct 2003 12:12:00 -0700 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id h93JBHRT023993; Fri, 3 Oct 2003 14:11:17 -0500 Received: (from oxymoron@localhost) by waste.org (8.12.3/8.12.3/Debian-6.6) id h93JBG1Q023991; Fri, 3 Oct 2003 14:11:16 -0500 Date: Fri, 3 Oct 2003 14:11:16 -0500 From: Matt Mackall To: jamal Cc: netdev@oss.sgi.com, Andrew Morton , Jeff Garzik Subject: Re: [RFC] [PATCH 1/3] netpoll api Message-ID: <20031003191116.GA13573@waste.org> References: <20031003014104.GR1897@waste.org> <1065179359.1031.42.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1065179359.1031.42.camel@jzny.localdomain> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new X-archive-position: 519 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev On Fri, Oct 03, 2003 at 07:09:20AM -0400, jamal wrote: > Hi, > > > On Thu, 2003-10-02 at 21:41, Matt Mackall wrote: > > This patch implements a new netpoll API, which allows sending and > > receiving packets in context where interrupts may be disabled. It > > provides a common API for implementing features like netconsole, > > netdump/LKCD, and kgdb-over-ethernet and manages to isolate them > > almost completely from the details of the network layer. > > > > Nice. > Is the ethernet card in a case like this almost dedicated for this > kind of work? No, I've had good results with it as the only interface to the machine. As netpoll traffic is fairly infrequent, performance seems little affected. > Is disable_irq() in the controller safe for shared irqs? Or maybe this > is critical enough that you dont care? I'm not aware of any issues there. I understand Red Hat has banged on this piece pretty heavily recently for their AS kernel. > Its a little wasteful to call the controller when there are is no work > to be done; we have found in NAPI that any extra PCI transactions cost. > (some IBM people doing benchmarking have complained about specweb not > looking good where NAPI will have one extra PCI transaction per packet. > You do it twice the rate NAPI would do it at low speeds). > Again, the answer maybe who cares, this is critical work. Just to be sure you read this right, the poll method (NAPI) is different from poll_controller (netpoll). The name is unfortunate, but it's what Ingo had in his early 2.4 netconsole patches. I could s/poll_controller/netpoll/ perhaps. The NAPI method only gets called when we've frozen the system (kgdb or netdump) and we're the only ones checking for rx work. The netpoll method gets called in that case and when something like netconsole is sending out printks (eg low bandwidth or high priority). > Have you done any measurements to check whether it was worthwile to do > the skb preallocation? Yes, one of the longer sysrq dumps could knock over earlier versions of the code. -- Matt Mackall : http://www.selenic.com : of or relating to the moon From fubar@us.ibm.com Fri Oct 3 12:58:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 12:59:18 -0700 (PDT) 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 h93Jwc25026115 for ; Fri, 3 Oct 2003 12:58:45 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id h93JvuYN816952; Fri, 3 Oct 2003 15:57:56 -0400 Received: from death.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h93JvrEx199050; Fri, 3 Oct 2003 15:57:55 -0400 Received: from us.ibm.com (fubar@localhost) by death.ibm.com (8.12.5/8.12.5/Submit) with ESMTP id h93Jva1U004043; Fri, 3 Oct 2003 12:57:37 -0700 Message-Id: <200310031957.h93Jva1U004043@death.ibm.com> X-Authentication-Warning: death.ibm.com: fubar owned process doing -bs To: shmulik.hen@intel.com cc: "David S. Miller" , "Chad N. Tindel" , jgarzik@pobox.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] Re: [bonding] compatibilty issues In-Reply-To: Message from Shmulik Hen of "Thu, 02 Oct 2003 09:37:51 +0300." <200310020937.51781.shmulik.hen@intel.com> Date: Fri, 03 Oct 2003 12:57:35 -0700 From: Jay Vosburgh X-archive-position: 520 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev >Where should such a list go ? Oh, I was thinking either in a comment block (by the ABI version definitions, for example), tacked on to the end of bonding.txt, or maybe in a README.ABI in the bonding/ directory. I'm not too concerned about where it is. I just don't want to find ourselves a year or two down the road trying to figure out just what ABI version N is supposed to do when it suddenly quits working.... -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From mitch@sfgoth.com Fri Oct 3 14:36:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 14:37:22 -0700 (PDT) Received: from gaz.sfgoth.com ([63.205.85.133]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h93Lak25003910 for ; Fri, 3 Oct 2003 14:36:47 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.9p1/8.12.9) with ESMTP id h93Ljg16077940; Fri, 3 Oct 2003 14:45:42 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.9p1/8.12.6/Submit) id h93LjfFr077939; Fri, 3 Oct 2003 14:45:41 -0700 (PDT) (envelope-from mitch) Date: Fri, 3 Oct 2003 14:45:41 -0700 From: Mitchell Blank Jr To: "David S. Miller" Cc: chas3@users.sourceforge.net, chas@cmf.nrl.navy.mil, netdev@oss.sgi.com Subject: Re: [RFC] add rtnl semaphore to linux-atm Message-ID: <20031003214541.GA73152@gaz.sfgoth.com> References: <200310011134.h91BYPkT003172@ginger.cmf.nrl.navy.mil> <20031001054226.126cea7b.davem@redhat.com> <20031003022615.GA42593@gaz.sfgoth.com> <20031003065824.713627c6.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031003065824.713627c6.davem@redhat.com> User-Agent: Mutt/1.4.1i X-archive-position: 521 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev David S. Miller wrote: > > My personal recommendations: > > * There should be a per-atm-device semaphore held across calls into the > > driver's ->open, ->close, ->change_qos and maybe a couple other things > > to serialize those operations (for the sake of keeping the drivers > > sane - there's no reason there should be multiple operations pending) > > Ok, but what Chas is trying to do is move the ATM device stuff over > to a model that makes use of the existing network device infrastructure > for solving these kinds of problems. > > Part of that is using the rtnl semaphore etc. > > I would rather Chas use the rtnl semaphore for synchronization > than to ultra-optimize this code by using the rwlock as I had suggested > to him. I have no problem with using rtnl_sem to syncronize the atmdev->{open, close,change_qos}() paths instead of a per-device semaphore. We *can't* use it to protect the state of the vcc list though because we need to do lookups in both interrupt and bh context. Using a sleeping lock alone is a non-starter. That's why we need to do the three-step spinlock->semaphore->spinlock dance in the vcc open and close paths. -Mitch From shemminger@osdl.org Fri Oct 3 14:46:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 14:47:27 -0700 (PDT) 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 h93Lks25004963 for ; Fri, 3 Oct 2003 14:46:54 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h93Lkg108707; Fri, 3 Oct 2003 14:46:45 -0700 Date: Fri, 3 Oct 2003 14:46:16 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (1/2) fix sppp device pointer Message-Id: <20031003144616.11a6b6c5.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 522 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 My bad, a change I put in while debugging the sealevel driver broke all the other sync drivers. The SPPP drivers expect that netdev->priv points to device local structure whose first element is a pointer to the ppp device. The bug was in sppp_of change that got rid of one level of indirection. To prevent future stupidity, do some reverse lookup check in sppp_attach and sppp_of. diff -Nru a/drivers/net/wan/syncppp.c b/drivers/net/wan/syncppp.c --- a/drivers/net/wan/syncppp.c Fri Oct 3 11:28:23 2003 +++ b/drivers/net/wan/syncppp.c Fri Oct 3 11:28:23 2003 @@ -1069,6 +1069,9 @@ struct sppp *sp = &pd->sppp; unsigned long flags; + /* Make sure embedding is safe for sppp_of */ + BUG_ON(sppp_of(dev) != sp); + spin_lock_irqsave(&spppq_lock, flags); /* Initialize keepalive handler. */ if (! spppq) diff -Nru a/include/net/syncppp.h b/include/net/syncppp.h --- a/include/net/syncppp.h Fri Oct 3 11:28:23 2003 +++ b/include/net/syncppp.h Fri Oct 3 11:28:23 2003 @@ -59,8 +59,9 @@ static inline struct sppp *sppp_of(struct net_device *dev) { - struct ppp_device *ppp = dev->priv; - return &ppp->sppp; + struct ppp_device **ppp = dev->priv; + BUG_ON((*ppp)->dev != dev); + return &(*ppp)->sppp; } #define PP_KEEPALIVE 0x01 /* use keepalive protocol */ From shemminger@osdl.org Fri Oct 3 14:48:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 14:49:04 -0700 (PDT) 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 h93LmV25005314 for ; Fri, 3 Oct 2003 14:48:31 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h93LmO109526; Fri, 3 Oct 2003 14:48:24 -0700 Date: Fri, 3 Oct 2003 14:47:58 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] sppp - fix sealevel Message-Id: <20031003144758.78c52154.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.5claws (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: 523 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 My earlier change broke the if_ptr assumption used by SPPP drivers. This makes sealevel driver do if_ptr like it used to. diff -Nru a/drivers/net/wan/sealevel.c b/drivers/net/wan/sealevel.c --- a/drivers/net/wan/sealevel.c Fri Oct 3 11:28:36 2003 +++ b/drivers/net/wan/sealevel.c Fri Oct 3 11:28:36 2003 @@ -31,6 +31,7 @@ struct slvl_device { + void *if_ptr; /* General purpose pointer (used by SPPP) */ struct z8530_channel *chan; struct ppp_device pppdev; int channel; @@ -238,6 +239,7 @@ return NULL; sv = d->priv; + sv->if_ptr = &sv->pppdev; sv->pppdev.dev = d; d->base_addr = iobase; d->irq = irq; From rddunlap@osdl.org Fri Oct 3 21:36:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 21:36:50 -0700 (PDT) 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 h944aF25024840 for ; Fri, 3 Oct 2003 21:36:16 -0700 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 h944a8116207; Fri, 3 Oct 2003 21:36:08 -0700 Date: Fri, 3 Oct 2003 21:29:04 -0700 From: "Randy.Dunlap" To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Subject: [PATCH] janitor: insert missing iounmap(), add error handling Message-Id: <20031003212904.34d4ca01.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: 524 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 Hi, Please apply to 2.6.0-test6-current. Thanks, -- ~Randy From: Leann Ogasawara Subject: Re: [Kernel-janitors] [PATCH] insert missing iounmap() > > Patch inserts a missing iounmap(). Implements a cleanup path > > for error handling as well. Feedback is much appreciated. Thanks :) ===== drivers/net/natsemi.c 1.55 vs edited ===== linux-260-test6-kj1-rddunlap/drivers/net/natsemi.c | 39 ++++++++++----------- 1 files changed, 20 insertions(+), 19 deletions(-) diff -puN drivers/net/natsemi.c~net_natsemi_iounmap drivers/net/natsemi.c --- linux-260-test6-kj1/drivers/net/natsemi.c~net_natsemi_iounmap 2003-09-29 17:37:59.000000000 -0700 +++ linux-260-test6-kj1-rddunlap/drivers/net/natsemi.c 2003-09-29 17:37:59.000000000 -0700 @@ -765,19 +765,13 @@ static int __devinit natsemi_probe1 (str SET_NETDEV_DEV(dev, &pdev->dev); i = pci_request_regions(pdev, dev->name); - if (i) { - free_netdev(dev); - return i; - } + if (i) + goto err_pci_request_regions; - { - void *mmio = ioremap (ioaddr, iosize); - if (!mmio) { - pci_release_regions(pdev); - free_netdev(dev); - return -ENOMEM; - } - ioaddr = (unsigned long) mmio; + ioaddr = (unsigned long) ioremap (ioaddr, iosize); + if (!ioaddr) { + i = -ENOMEM; + goto err_ioremap; } /* Work around the dropped serial bit. */ @@ -835,13 +829,9 @@ static int __devinit natsemi_probe1 (str dev->mtu = mtu; i = register_netdev(dev); - if (i) { - pci_release_regions(pdev); - unregister_netdev(dev); - free_netdev(dev); - pci_set_drvdata(pdev, NULL); - return i; - } + if (i) + goto err_register_netdev; + netif_carrier_off(dev); if (netif_msg_drv(np)) { @@ -878,6 +868,17 @@ static int __devinit natsemi_probe1 (str return 0; + + err_register_netdev: + iounmap ((void *) dev->base_addr); + + err_ioremap: + pci_release_regions(pdev); + pci_set_drvdata(pdev, NULL); + + err_pci_request_regions: + free_netdev(dev); + return i; } _ From rddunlap@osdl.org Fri Oct 3 21:36:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 21:36:50 -0700 (PDT) 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 h944aF25024839 for ; Fri, 3 Oct 2003 21:36:16 -0700 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 h944a9116212; Fri, 3 Oct 2003 21:36:09 -0700 Date: Fri, 3 Oct 2003 21:35:17 -0700 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: ncorbic@sangoma.com, davem@redhat.com Subject: [PATCH] janitor: remove verify_area() in net/wan/sbni Message-Id: <20031003213517.6700a095.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: 524 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 Hi, Please apply to 2.6.0-test6-current. Thanks, -- ~Randy From: Domen Puncer Subject: [Kernel-janitors] [PATCH] updated: verify_area: drivers/net/wan/sbni.c Someone added error checking to copy_*_user, so this [earlier] patch didn't apply. Removed unnecessary verify_area. linux-260-test6-kj1-rddunlap/drivers/net/wan/sbni.c | 20 +++++--------------- 1 files changed, 5 insertions(+), 15 deletions(-) diff -puN drivers/net/wan/sbni.c~net_wan_sbni_verify drivers/net/wan/sbni.c --- linux-260-test6-kj1/drivers/net/wan/sbni.c~net_wan_sbni_verify 2003-09-29 17:39:09.000000000 -0700 +++ linux-260-test6-kj1-rddunlap/drivers/net/wan/sbni.c 2003-09-29 17:39:09.000000000 -0700 @@ -1300,12 +1300,9 @@ sbni_ioctl( struct net_device *dev, st switch( cmd ) { case SIOCDEVGETINSTATS : - error = verify_area( VERIFY_WRITE, ifr->ifr_data, - sizeof(struct sbni_in_stats) ); - if( !error ) - if (copy_to_user( ifr->ifr_data, &nl->in_stats, - sizeof(struct sbni_in_stats) )) - return -EFAULT; + if (copy_to_user( ifr->ifr_data, &nl->in_stats, + sizeof(struct sbni_in_stats) )) + error = -EFAULT; break; case SIOCDEVRESINSTATS : @@ -1321,11 +1318,8 @@ sbni_ioctl( struct net_device *dev, st flags.rxl = nl->cur_rxl_index; flags.fixed_rxl = nl->delta_rxl == 0; - error = verify_area( VERIFY_WRITE, ifr->ifr_data, - sizeof flags ); - if( !error ) - if (copy_to_user( ifr->ifr_data, &flags, sizeof flags )) - return -EFAULT; + if (copy_to_user( ifr->ifr_data, &flags, sizeof flags )) + error = -EFAULT; break; case SIOCDEVSHWSTATE : @@ -1353,10 +1347,6 @@ sbni_ioctl( struct net_device *dev, st if( current->euid != 0 ) /* root only */ return -EPERM; - if( (error = verify_area( VERIFY_READ, ifr->ifr_data, - sizeof slave_name )) != 0 ) - return error; - if (copy_from_user( slave_name, ifr->ifr_data, sizeof slave_name )) return -EFAULT; slave_dev = dev_get_by_name( slave_name ); _ From davem@pizda.ninka.net Fri Oct 3 22:21:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 22:21:43 -0700 (PDT) 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 h945L925028276 for ; Fri, 3 Oct 2003 22:21:09 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id WAA26455; Fri, 3 Oct 2003 22:16:40 -0700 Date: Fri, 3 Oct 2003 22:16:40 -0700 From: "David S. Miller" To: Mitchell Blank Jr Cc: chas3@users.sourceforge.net, chas@cmf.nrl.navy.mil, netdev@oss.sgi.com Subject: Re: [RFC] add rtnl semaphore to linux-atm Message-Id: <20031003221640.19aa485f.davem@redhat.com> In-Reply-To: <20031003214541.GA73152@gaz.sfgoth.com> References: <200310011134.h91BYPkT003172@ginger.cmf.nrl.navy.mil> <20031001054226.126cea7b.davem@redhat.com> <20031003022615.GA42593@gaz.sfgoth.com> <20031003065824.713627c6.davem@redhat.com> <20031003214541.GA73152@gaz.sfgoth.com> X-Mailer: Sylpheed version 0.9.2 (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: 525 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, 3 Oct 2003 14:45:41 -0700 Mitchell Blank Jr wrote: > We *can't* use it to protect the state of the vcc list though because we > need to do lookups in both interrupt and bh context. Using a sleeping > lock alone is a non-starter. > > That's why we need to do the three-step spinlock->semaphore->spinlock > dance in the vcc open and close paths. The semaphore protects "modifications", it basically serializes them. You still need a rwlock to protect the actual lists and this rwlock is what the interrupt/bh context code takes to traverse the lists and tables. This is how the netdev list works, for example. From mitch@sfgoth.com Fri Oct 3 22:46:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 22:47:03 -0700 (PDT) Received: from gaz.sfgoth.com ([63.205.85.133]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h945kT25030160 for ; Fri, 3 Oct 2003 22:46:29 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.9p1/8.12.9) with ESMTP id h945tR16093033; Fri, 3 Oct 2003 22:55:27 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.9p1/8.12.6/Submit) id h945tQvw093032; Fri, 3 Oct 2003 22:55:26 -0700 (PDT) (envelope-from mitch) Date: Fri, 3 Oct 2003 22:55:26 -0700 From: Mitchell Blank Jr To: "David S. Miller" Cc: chas3@users.sourceforge.net, chas@cmf.nrl.navy.mil, netdev@oss.sgi.com Subject: Re: [RFC] add rtnl semaphore to linux-atm Message-ID: <20031004055526.GG73152@gaz.sfgoth.com> References: <200310011134.h91BYPkT003172@ginger.cmf.nrl.navy.mil> <20031001054226.126cea7b.davem@redhat.com> <20031003022615.GA42593@gaz.sfgoth.com> <20031003065824.713627c6.davem@redhat.com> <20031003214541.GA73152@gaz.sfgoth.com> <20031003221640.19aa485f.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031003221640.19aa485f.davem@redhat.com> User-Agent: Mutt/1.4.1i X-archive-position: 526 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev David S. Miller wrote: > > We *can't* use it to protect the state of the vcc list though because we > > need to do lookups in both interrupt and bh context. Using a sleeping > > lock alone is a non-starter. > > > > That's why we need to do the three-step spinlock->semaphore->spinlock > > dance in the vcc open and close paths. > > The semaphore protects "modifications", it basically serializes them. > > You still need a rwlock to protect the actual lists and this rwlock > is what the interrupt/bh context code takes to traverse the lists > and tables. I think we're saying approximately the same thing at this point. I'm just trying to make the point that the spinlock (or rwlock, whatever) can't be held when we call atm_dev->{open,close}() since they can sleep. Which is why we need to do the three-step process I described in the earlier email. Once you do that there's no reason (that I know of) to take rtnl_sem except to serialize the actual calls into atm_dev's ops. There's no problem if multiple opens both get their vpi/vci's allocated in "inactive" state as long as the actual connects happen in series. -Mitch From davem@pizda.ninka.net Fri Oct 3 23:00:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 23:00:55 -0700 (PDT) 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 h9460L25031376 for ; Fri, 3 Oct 2003 23:00:22 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id WAA26596; Fri, 3 Oct 2003 22:55:52 -0700 Date: Fri, 3 Oct 2003 22:55:52 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [RFT] syncppp needs to pullup headers Message-Id: <20031003225552.3c8f28d9.davem@redhat.com> In-Reply-To: <20031003114347.31ee740b.shemminger@osdl.org> References: <20031003114347.31ee740b.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (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: 527 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, 3 Oct 2003 11:43:47 -0700 Stephen Hemminger wrote: > In 2.6.0-test6 wan syncppp driver claims to be a "new" protocol and handle shared skb's > but it needs to make sure data is contiguous before overlaying headers. > It is not a serious problem because the sync drivers never generate nonlinear skbuff's > anyway. This looks obvious enough and correct to me, applied. From davem@pizda.ninka.net Fri Oct 3 23:10:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 23:11:11 -0700 (PDT) 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 h946Aa25032378 for ; Fri, 3 Oct 2003 23:10:37 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA26656; Fri, 3 Oct 2003 23:06:06 -0700 Date: Fri, 3 Oct 2003 23:06:06 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jt@hpl.hp.com, jt@bougret.hpl.hp.com, irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (1/11) Irda dongle module owner support (revised) Message-Id: <20031003230606.6a35677e.davem@redhat.com> In-Reply-To: <20031003102133.2e5a41a2.shemminger@osdl.org> References: <20031002152026.4bfd2c67.shemminger@osdl.org> <20031002233335.GA7945@bougret.hpl.hp.com> <20031003102133.2e5a41a2.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (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: 528 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, 3 Oct 2003 10:21:33 -0700 Stephen Hemminger wrote: > Revised version of the dongle module owner patch, incorporating Jean's comments. > This replaces the original patch. It provides an owner field an appropriate > ref counting for IRDA dongles. I applied this, but where's the necessary IRDA header file change that adds the 'owner' field to the dongle_reg structure? It's missing from this patch. Please send me that, and then I assume that I can just suck in all of your individual IRDA driver patches from yesterday? From davem@pizda.ninka.net Fri Oct 3 23:15:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 23:15:39 -0700 (PDT) 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 h946F625000505 for ; Fri, 3 Oct 2003 23:15:06 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA26703; Fri, 3 Oct 2003 23:10:35 -0700 Date: Fri, 3 Oct 2003 23:10:35 -0700 From: "David S. Miller" To: "Randy.Dunlap" Cc: netdev@oss.sgi.com, ncorbic@sangoma.com Subject: Re: [PATCH] janitor: remove verify_area() in net/wan/sbni Message-Id: <20031003231035.7aa33bd3.davem@redhat.com> In-Reply-To: <20031003213517.6700a095.rddunlap@osdl.org> References: <20031003213517.6700a095.rddunlap@osdl.org> X-Mailer: Sylpheed version 0.9.2 (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: 529 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, 3 Oct 2003 21:35:17 -0700 "Randy.Dunlap" wrote: > Please apply to 2.6.0-test6-current. Applied, thanks Randy. From mitch@sfgoth.com Fri Oct 3 23:47:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 23:48:03 -0700 (PDT) Received: from gaz.sfgoth.com ([63.205.85.133]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h946lT25002874 for ; Fri, 3 Oct 2003 23:47:29 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.9p1/8.12.9) with ESMTP id h946uT16094516; Fri, 3 Oct 2003 23:56:30 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.9p1/8.12.6/Submit) id h946uTnZ094515; Fri, 3 Oct 2003 23:56:29 -0700 (PDT) (envelope-from mitch) Date: Fri, 3 Oct 2003 23:56:29 -0700 From: Mitchell Blank Jr To: "David S. Miller" Cc: chas3@users.sourceforge.net, chas@cmf.nrl.navy.mil, netdev@oss.sgi.com Subject: Re: [RFC] add rtnl semaphore to linux-atm Message-ID: <20031004065629.GA94203@gaz.sfgoth.com> References: <200310011134.h91BYPkT003172@ginger.cmf.nrl.navy.mil> <20031001054226.126cea7b.davem@redhat.com> <20031003022615.GA42593@gaz.sfgoth.com> <20031003065824.713627c6.davem@redhat.com> <20031003214541.GA73152@gaz.sfgoth.com> <20031003221640.19aa485f.davem@redhat.com> <20031004055526.GG73152@gaz.sfgoth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031004055526.GG73152@gaz.sfgoth.com> User-Agent: Mutt/1.4.1i X-archive-position: 530 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev Mitchell Blank Jr wrote: > I'm just trying to make the point that the spinlock (or rwlock, whatever) > can't be held when we call atm_dev->{open,close}() since they can sleep. > Which is why we need to do the three-step process I described in the > earlier email. Actually I guess there's two ways of doing it... so instead of Method 1: 1. Take rwlock for writing 2. Search for {dev,vpi,vci} tuple. If found, fail - otherwise add it as "inactive" 3. Drop rwlock 4. Take semaphore 5. Call atm_dev->open() 6. Drop semaphore 7. Take rwlock for writing 8. If open succeeded clear "inactive" flag. If failed remove entry 9. Drop rwlock Method 2: 1. Take semaphore 2. Take rwlock for reading 3. Search for tuple, if found fail 4. Drop rwlock 5. Call atm_dev->open 6. Take rwlock for writing 7. Add tuple to list 8. Drop rwlock 9. Drop semaphore The second method has the advantage that you don't need the "inactive" flag. On the other hand, you have to wait for the semaphore before you can return EADDRINUSE. -Mitch From ookhoi@humilis.net Fri Oct 3 23:49:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 23:50:28 -0700 (PDT) Received: from favonius.humilis.net (ookhoi.xs4all.nl [213.84.114.66]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h946nq25003313 for ; Fri, 3 Oct 2003 23:49:53 -0700 Received: by favonius.humilis.net (Postfix, from userid 1000) id 6A82EB0127; Sat, 4 Oct 2003 08:49:52 +0200 (CEST) Date: Sat, 4 Oct 2003 08:49:52 +0200 From: Sander To: "Leech, Christopher" Cc: ookhoi@humilis.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: e1000 -> 82540EM on linux 2.6.0-test[45] very slow in one direction Message-ID: <20031004064952.GA27027@favonius> Reply-To: sander@humilis.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Uptime: 07:59:12 up 117 days, 7:32, 34 users, load average: 1.32, 1.07, 1.02 User-Agent: Mutt/1.5.4i X-archive-position: 531 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sander@humilis.net Precedence: bulk X-list: netdev Leech, Christopher wrote (ao): > > Btw, I had to compile the e1000 driver as a module. Compiled in it > > doesn't work, as is stated on the intel support page: > > > This is not clear from the kernel config help. A patch against > > 2.6.0-test6 is attached (I don't know how to only give n/m as an > > option). > > This patch is not necessary or desired. The version of e1000 that ships > with the kernel source should work fine statically linked, and the > comment on the Intel support web page applies to the separate download > of the e1000 source. If you download the driver source from Intel and > do the work to add it into a kernel source tree yourself, Intel customer > support may not help you when you have problems. > > If you are having problems compiling in the version of e1000 that ships > with the kernel, please report it on netdev and we'll try and help. I'm sorry for the patch. The problem I had with e1000 compiled into the kernel was that the interface resets every 60(?) seconds, and there was no network connection. After a google search I came onto the intel support page, saw the module-only text, tried e1000 as a module and it worked. This all is with the e1000 driver which is in the 2.6.0-test6 kernel, which I thought was the intel provided driver. The server is co-located now, so I'm sorry to say that I can't try again to give more details. > > Btw2, can somebody please explain what the option E1000_NAPI does? > > NAPI is a network driver polling mode interface. It enables a form of > software managed interrupt moderation, and may result in better > performance under some traffic patterns (specifically sustained high > packet rate reception). Aha, tnx. Can you please provide a patch to get this text in the 2.6 help? From mitch@sfgoth.com Fri Oct 3 23:50:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Oct 2003 23:50:57 -0700 (PDT) Received: from gaz.sfgoth.com ([63.205.85.133]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h946oO25003405 for ; Fri, 3 Oct 2003 23:50:24 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.9p1/8.12.9) with ESMTP id h946xP16094554; Fri, 3 Oct 2003 23:59:25 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.9p1/8.12.6/Submit) id h946xPi7094553; Fri, 3 Oct 2003 23:59:25 -0700 (PDT) (envelope-from mitch) Date: Fri, 3 Oct 2003 23:59:25 -0700 From: Mitchell Blank Jr To: "David S. Miller" Cc: chas3@users.sourceforge.net, chas@cmf.nrl.navy.mil, netdev@oss.sgi.com Subject: Re: [RFC] add rtnl semaphore to linux-atm Message-ID: <20031004065925.GB94203@gaz.sfgoth.com> References: <200310011134.h91BYPkT003172@ginger.cmf.nrl.navy.mil> <20031001054226.126cea7b.davem@redhat.com> <20031003022615.GA42593@gaz.sfgoth.com> <20031003065824.713627c6.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031003065824.713627c6.davem@redhat.com> User-Agent: Mutt/1.4.1i X-archive-position: 532 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev David S. Miller wrote: > Part of that is using the rtnl semaphore etc. I've thought about this some more and I think we really DO want a per-atm-device semaphore for this rather than overloading rtnl_sem. A device like an ADSL card might need to do a complete physical-layer negotiation when you open a VCC (assuming there were no VCCs open before) This could take on the order of a minute if it fails. You don't want to be hogging rtnl_sem for that long. -Mitch From chas@cmf.nrl.navy.mil Sat Oct 4 05:50:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Oct 2003 05:50:41 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h94Co625026376 for ; Sat, 4 Oct 2003 05:50:06 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id h94Co0kT017402; Sat, 4 Oct 2003 08:50:00 -0400 (EDT) Message-Id: <200310041250.h94Co0kT017402@ginger.cmf.nrl.navy.mil> To: Mitchell Blank Jr cc: "David S. Miller" , netdev@oss.sgi.com Reply-To: chas3@users.sourceforge.net Subject: Re: [RFC] add rtnl semaphore to linux-atm In-reply-to: Your message of "Fri, 03 Oct 2003 23:59:25 PDT." <20031004065925.GB94203@gaz.sfgoth.com> Date: Sat, 04 Oct 2003 08:50:00 -0400 From: chas williams X-Spam-Score: (*) hits=1.7 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 533 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev just to summarize the last couple messages and my thoughts about all of this: atm_dev will become a netdevice in the future. there is no good reason it shouldnt. the atm layer needs to start doing things the 'netdevice' way. ATM_ITF_ANY is rarely used. we just need it to work properly with a minimum of effort. the rtnl semaphore blocks modifications to the device list so routines that might sleep can safely iterate it. there are (currently) no atm devices with slow open routines so please dont bother with hypothetical devices. people who use ATM_ITF_ANY are going to pay a penalty. that's just the way it is. its a bit of a bad idea really. what if you want something like round-robin instead of in-order? should vcc->open() and vcc->close() sleep? this is a problem for some people. i can see why you might want to sleep in close() -- like waiting for all the skb's to transmit/return, but this is only because vcc's dont hold a per skb reference count and dont know when its safe to go away (and this becuase the atm transmit side doesnt skb_clone() like it should). serialization for open/change_qos/close should be handled in the driver (assuming we are discussing serialization across different vcc's and not a single vcc -- a single vcc case is already handled via lock_sock). if your driver h/w doesnt need this, then it shouldnt be thrust upon you. further, i believe this is wrong thinking. what data are you protecting with this lock? (the he driver has a 'global' lock, but its used to protect the register space, which has a serialization effect). vcc_sklist holds a list of sockets active or otherwise. the atm layer already has flags (ATM_VF_READY) that indicate if a vcc is ready to recv. it is unfortunate that the bh's of most drivers dont bother to check this bit (assuming some other mechanism isnt used to prevent the bottom half from running while opening/preparing a vcc). in the future (and this isnt a hypothetical driver) vcc's will probably live slightly longer than the close routine (those outstanding skbs) and cant be removed from the vcc_sklist until every last reference is gone. yes, this means that close could finish but you wouldnt be able to open the vpi/vci again right away. From mitch@sfgoth.com Sat Oct 4 12:42:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Oct 2003 12:43:17 -0700 (PDT) Received: from gaz.sfgoth.com ([63.205.85.133]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h94Jge25016146 for ; Sat, 4 Oct 2003 12:42:41 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.9p1/8.12.9) with ESMTP id h94Jgh16013332; Sat, 4 Oct 2003 12:42:43 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.9p1/8.12.6/Submit) id h94Jghw3013331; Sat, 4 Oct 2003 12:42:43 -0700 (PDT) (envelope-from mitch) Date: Sat, 4 Oct 2003 12:42:42 -0700 From: Mitchell Blank Jr To: chas3@users.sourceforge.net Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [RFC] add rtnl semaphore to linux-atm Message-ID: <20031004194242.GC94203@gaz.sfgoth.com> References: <20031004065925.GB94203@gaz.sfgoth.com> <200310041250.h94Co0kT017402@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310041250.h94Co0kT017402@ginger.cmf.nrl.navy.mil> User-Agent: Mutt/1.4.1i X-archive-position: 534 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev chas williams wrote: > atm_dev will become a netdevice in the future. there is no good reason > it shouldnt. Agreed. I'm not sure if it's a giant win (since atm devices are pretty unique) but you seem pretty gung-ho about converting it so I'll trust you on it. > there are > (currently) no atm devices with slow open routines so please dont bother > with hypothetical devices. Well that might be true in the tree. I think as more DSL adpaters are supported this will change. The atm_dev->open() is really the only sane place currently to kick-off DSL negotiation (so the link is brought up when pppd or whatever is started) > people who use ATM_ITF_ANY are going to pay > a penalty. that's just the way it is. its a bit of a bad idea really. > what if you want something like round-robin instead of in-order? Exactly - its a userspace problem. > i can see why you might want to sleep in close() -- like waiting > for all the skb's to transmit/return, but this is only because vcc's dont > hold a per skb reference count and dont know when its safe to go away I can't speak for all the cards but at least lanai.c has to sleep in ->close() due to hardware issues. Each VCC has its own cell buffers allocated which the card DMAs into. When you close a vcc you need to wait for an internal RX queue to drain before you can safely free the buffer or you might end up scribbling on random memory. The only alternative I can think of would be to have the buffer free kicked off later from a tasklet or someting but that could get pretty gross. Plus as I mentioned DSL adapters have good reason to sleep in open/close. Since we require VCCs to be opened and closed from process context this isn't a problem (as long as we do the locking correctly) > serialization for open/change_qos/close should be handled in the > driver (assuming we are discussing serialization across different > vcc's and not a single vcc -- a single vcc case is already > handled via lock_sock). if your driver h/w doesnt need this, then > it shouldnt be thrust upon you. Its a matter of opinion. My feelings are: 1. Serializing these operations through a semaphore shouldn't affect performance one bit - even in conditions where open/close happen relatively frequently (say, LANE) there would still be negligable contention on the semaphore 2. Given the rather spotty history of ATM drivers and SMP I'd rather keep the driver API as safe as possible. Basically the driver should only have to worry about locking when dealing with the rx/tx paths (and there are still lots of problems there I think) Everything else can be safely serialized by the ATM layer > vcc_sklist holds a list of sockets active or otherwise. the atm layer > already has flags (ATM_VF_READY) that indicate if a vcc is ready to recv. Unfortunately the flag is currently managed by the driver instead of the ATM layer. If you're willing to strip out all of the ATM_VF_* use inside of the drivers then yes we can use that flag. > it is unfortunate that the bh's of most drivers dont bother to check this > bit This is just a matter of adding an efficient API for searching for vpi/vci's (as we recently discussed on l-a-g) If that was done then we could get rid of the duplicated data strucutres that exist in most of the drivers (and get rid of a whole class of races in the rx paths) Then the ATM layer can easily handle checking the ATM_VF_READY flag. > in the future (and this > isnt a hypothetical driver) vcc's will probably live slightly longer than > the close routine (those outstanding skbs) and cant be removed from the > vcc_sklist until every last reference is gone. yes, this means that close > could finish but you wouldnt be able to open the vpi/vci again right away. I don't think that's the case at all - you could safely remove the vcc from the list at ->close time (but not free its memory until the last reference disappears) Then an ->open would see the vpi/vci as free immediately (which should be safe) -Mitch From hadi@cyberus.ca Sat Oct 4 13:02:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Oct 2003 13:02:50 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h94K2F25017693 for ; Sat, 4 Oct 2003 13:02:15 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 1A5sbS-000Gpv-00; Sat, 04 Oct 2003 16:02:10 -0400 Subject: Re: [RFC] [PATCH 1/3] netpoll api From: jamal Reply-To: hadi@cyberus.ca To: Matt Mackall Cc: netdev@oss.sgi.com, Andrew Morton , Jeff Garzik In-Reply-To: <20031003191116.GA13573@waste.org> References: <20031003014104.GR1897@waste.org> <1065179359.1031.42.camel@jzny.localdomain> <20031003191116.GA13573@waste.org> Content-Type: text/plain Organization: jamalopolis Message-Id: <1065297729.1031.73.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Oct 2003 16:02:09 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 535 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 Fri, 2003-10-03 at 15:11, Matt Mackall wrote: > > Nice. > > Is the ethernet card in a case like this almost dedicated for this > > kind of work? > > No, I've had good results with it as the only interface to the > machine. As netpoll traffic is fairly infrequent, performance seems > little affected. > Ok, I suppose if you are running some serious server you wont be debugging either. Did i understand correctly that no netpoll trafic translates to a device being removed from the poll list? i.e only when theres traffic to send for example would the controller be invoked? > > Is disable_irq() in the controller safe for shared irqs? Or maybe this > > is critical enough that you dont care? > > I'm not aware of any issues there. I understand Red Hat has banged on > this piece pretty heavily recently for their AS kernel. > Lets say you have a vga card and ethernet sharing the same irq and doing a lot of debugging ... would disabling that shared irq kill the display for example? > > Its a little wasteful to call the controller when there are is no work > > to be done; we have found in NAPI that any extra PCI transactions cost. > > (some IBM people doing benchmarking have complained about specweb not > > looking good where NAPI will have one extra PCI transaction per packet. > > You do it twice the rate NAPI would do it at low speeds). > > Again, the answer maybe who cares, this is critical work. > > Just to be sure you read this right, the poll method (NAPI) is > different from poll_controller (netpoll). The name is unfortunate, but > it's what Ingo had in his early 2.4 netconsole patches. I could > s/poll_controller/netpoll/ perhaps. > Actually the name is proper since polling is involved. I can see the confusion with NAPI - so from that angle changing it to something more descriptive of its function rather than how it achieves it would help. > The NAPI method only gets called when we've frozen the system (kgdb or > netdump) and we're the only ones checking for rx work. The netpoll > method gets called in that case and when something like netconsole is > sending out printks (eg low bandwidth or high priority). > netpoll calls the interupt handler which typically involved substantial PCI reads (and maybe writes). Calling such routines when theres no state change in the PCI registers is what i refered to as a waste. This is a non-issue under normal conditions since an interupt signals a state change. It wouldnt matter if it is event driven (i.e for a brief period of time when netconsole has traffic to send thats what you do). It also wouldnt matter if you are using the box as dev. environment etc. cheers, jamal From oxymoron@waste.org Sat Oct 4 13:33:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Oct 2003 13:34:28 -0700 (PDT) Received: from waste.org (waste.org [209.173.204.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h94KXp25020380 for ; Sat, 4 Oct 2003 13:33:52 -0700 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id h94KX8RT008304; Sat, 4 Oct 2003 15:33:08 -0500 Received: (from oxymoron@localhost) by waste.org (8.12.3/8.12.3/Debian-6.6) id h94KX4Ir008301; Sat, 4 Oct 2003 15:33:04 -0500 Date: Sat, 4 Oct 2003 15:33:04 -0500 From: Matt Mackall To: jamal Cc: netdev@oss.sgi.com, Andrew Morton , Jeff Garzik Subject: Re: [RFC] [PATCH 1/3] netpoll api Message-ID: <20031004203304.GD13573@waste.org> References: <20031003014104.GR1897@waste.org> <1065179359.1031.42.camel@jzny.localdomain> <20031003191116.GA13573@waste.org> <1065297729.1031.73.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1065297729.1031.73.camel@jzny.localdomain> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new X-archive-position: 536 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev On Sat, Oct 04, 2003 at 04:02:09PM -0400, jamal wrote: > On Fri, 2003-10-03 at 15:11, Matt Mackall wrote: > > > > Nice. > > > Is the ethernet card in a case like this almost dedicated for this > > > kind of work? > > > > No, I've had good results with it as the only interface to the > > machine. As netpoll traffic is fairly infrequent, performance seems > > little affected. > > > > Ok, I suppose if you are running some serious server you wont be > debugging either. Did i understand correctly that no netpoll trafic > translates to a device being removed from the poll list? i.e only when > theres traffic to send for example would the controller be invoked? Polling is only on demand. Eg, in the netconsole case, polling only happens to push a packet out when a printk occurs. In the netdump or kgdb case, the entire machine is essentially brought to a halt anyway, so overhead is irrelevant. > > > Is disable_irq() in the controller safe for shared irqs? Or maybe this > > > is critical enough that you dont care? > > > > I'm not aware of any issues there. I understand Red Hat has banged on > > this piece pretty heavily recently for their AS kernel. > > > > Lets say you have a vga card and ethernet sharing the same irq and doing > a lot of debugging ... would disabling that shared irq kill the display > for example? Yes. Again, in the netconsole case, this will only happen when a printk is occurring. Netconsole is primarily of interest for debugging or replacing serial console for headless servers. In the 'replacing serial console' case, it actually reduces overhead because polling the network is much faster than polling serial. > > > Its a little wasteful to call the controller when there are is no work > > > to be done; we have found in NAPI that any extra PCI transactions cost. > > > (some IBM people doing benchmarking have complained about specweb not > > > looking good where NAPI will have one extra PCI transaction per packet. > > > You do it twice the rate NAPI would do it at low speeds). > > > Again, the answer maybe who cares, this is critical work. > > > > Just to be sure you read this right, the poll method (NAPI) is > > different from poll_controller (netpoll). The name is unfortunate, but > > it's what Ingo had in his early 2.4 netconsole patches. I could > > s/poll_controller/netpoll/ perhaps. > > > > Actually the name is proper since polling is involved. I can see the > confusion with NAPI - so from that angle changing it to something > more descriptive of its function rather than how it achieves it would > help. Ok, netpoll it is. -- Matt Mackall : http://www.selenic.com : of or relating to the moon From oxymoron@waste.org Sat Oct 4 19:55:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Oct 2003 19:55:58 -0700 (PDT) Received: from waste.org (waste.org [209.173.204.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h952tM25007652 for ; Sat, 4 Oct 2003 19:55:23 -0700 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id h952tCRT009087; Sat, 4 Oct 2003 21:55:12 -0500 Received: (from oxymoron@localhost) by waste.org (8.12.3/8.12.3/Debian-6.6) id h952tCAH009085; Sat, 4 Oct 2003 21:55:12 -0500 Date: Sat, 4 Oct 2003 21:55:12 -0500 From: Matt Mackall To: Jeff Garzik Cc: netdev@oss.sgi.com, Andrew Morton Subject: Re: [RFC] [PATCH 2/3] tg3 netpoll hook Message-ID: <20031005025512.GF13573@waste.org> References: <20031003014505.GS1897@waste.org> <3F7F857D.5010504@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F7F857D.5010504@pobox.com> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new X-archive-position: 537 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev On Sat, Oct 04, 2003 at 10:44:13PM -0400, Jeff Garzik wrote: > Matt Mackall wrote: > > l-mpm/drivers/net/tg3.c | 16 ++++++++++++++++ > > 1 files changed, 16 insertions(+) > > > >diff -puN drivers/net/tg3.c~tg3-poll drivers/net/tg3.c > >+++ l-mpm/drivers/net/tg3.c 2003-09-25 11:56:37.000000000 -0500 > >@@ -2475,6 +2475,15 @@ static irqreturn_t tg3_interrupt(int irq > > static int tg3_init_hw(struct tg3 *); > > static int tg3_halt(struct tg3 *); > > > >+#ifdef HAVE_POLL_CONTROLLER > >+static void tg3_poll_controller(struct net_device *dev) > >+{ > >+ disable_irq(dev->irq); > >+ tg3_interrupt (dev->irq, dev, NULL); > >+ enable_irq(dev->irq); > >+} > >+#endif > >+ > > static void tg3_reset_task(void *_data) > > { > > struct tg3 *tp = _data; > >@@ -7482,6 +7491,10 @@ static struct pci_dev * __devinit tg3_fi > > return peer; > > } > > > >+#ifdef HAVE_POLL_CONTROLLER > >+static void tg3_poll_controller(struct net_device *dev); > >+#endif > > This prototype is pointless. Indeed. Have an opinion on s/->poll_controller/->netpoll/? -- Matt Mackall : http://www.selenic.com : of or relating to the moon From jgarzik@pobox.com Sat Oct 4 20:11:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Oct 2003 20:12:26 -0700 (PDT) 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 h953Bq25008163 for ; Sat, 4 Oct 2003 20:11:52 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:36263 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 1A5zJG-0001Xo-Un; Sun, 05 Oct 2003 04:11:51 +0100 Message-ID: <3F7F8BDF.5000903@pobox.com> Date: Sat, 04 Oct 2003 23:11:27 -0400 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: Matt Mackall CC: netdev@oss.sgi.com, Andrew Morton Subject: Re: [RFC] [PATCH 2/3] tg3 netpoll hook References: <20031003014505.GS1897@waste.org> <3F7F857D.5010504@pobox.com> <20031005025512.GF13573@waste.org> In-Reply-To: <20031005025512.GF13573@waste.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 538 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 Matt Mackall wrote: > Have an opinion on s/->poll_controller/->netpoll/? I have an opinion, yes :) which I despise myself for holding... I don't like either name, but don't have any better suggestions either, besides something extremely verbose like ->process_hw_events(). "poll_controller" is annoying because (a) it's way too close to NAPI, but (b) it's a reasonably accurate description of what it does. I think "netpoll" is even worse... It describes who calls it, not what it does. Jeff From kaos@ocs.com.au Sat Oct 4 20:16:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Oct 2003 20:16:59 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h953GO25008591 for ; Sat, 4 Oct 2003 20:16:25 -0700 Received: (qmail 8026 invoked from network); 5 Oct 2003 03:16:21 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 5 Oct 2003 03:16:21 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 4C66BC02B9; Sun, 5 Oct 2003 13:16:20 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 4A59A14008E; Sun, 5 Oct 2003 13:16:20 +1000 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Jeff Garzik Cc: Matt Mackall , netdev@oss.sgi.com, Andrew Morton Subject: Re: [RFC] [PATCH 2/3] tg3 netpoll hook In-reply-to: Your message of "Sat, 04 Oct 2003 23:11:27 -0400." <3F7F8BDF.5000903@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 05 Oct 2003 13:16:19 +1000 Message-ID: <31674.1065323779@ocs3.intra.ocs.com.au> X-archive-position: 539 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaos@ocs.com.au Precedence: bulk X-list: netdev On Sat, 04 Oct 2003 23:11:27 -0400, Jeff Garzik wrote: >Matt Mackall wrote: >> Have an opinion on s/->poll_controller/->netpoll/? >I don't like either name, but don't have any better suggestions either, >besides something extremely verbose like ->process_hw_events(). > >"poll_controller" is annoying because (a) it's way too close to NAPI, >but (b) it's a reasonably accurate description of what it does. > >I think "netpoll" is even worse... It describes who calls it, not what >it does. ->polled_io ? From jgarzik@pobox.com Sat Oct 4 21:17:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Oct 2003 21:17:45 -0700 (PDT) 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 h954HA25012058 for ; Sat, 4 Oct 2003 21:17:11 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:36231 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 1A5ysu-0001LY-Gy; Sun, 05 Oct 2003 03:44:36 +0100 Message-ID: <3F7F857D.5010504@pobox.com> Date: Sat, 04 Oct 2003 22:44:13 -0400 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: Matt Mackall CC: netdev@oss.sgi.com, Andrew Morton Subject: Re: [RFC] [PATCH 2/3] tg3 netpoll hook References: <20031003014505.GS1897@waste.org> In-Reply-To: <20031003014505.GS1897@waste.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 541 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 Matt Mackall wrote: > l-mpm/drivers/net/tg3.c | 16 ++++++++++++++++ > 1 files changed, 16 insertions(+) > > diff -puN drivers/net/tg3.c~tg3-poll drivers/net/tg3.c > --- l/drivers/net/tg3.c~tg3-poll 2003-09-25 11:47:30.000000000 -0500 > +++ l-mpm/drivers/net/tg3.c 2003-09-25 11:56:37.000000000 -0500 > @@ -2475,6 +2475,15 @@ static irqreturn_t tg3_interrupt(int irq > static int tg3_init_hw(struct tg3 *); > static int tg3_halt(struct tg3 *); > > +#ifdef HAVE_POLL_CONTROLLER > +static void tg3_poll_controller(struct net_device *dev) > +{ > + disable_irq(dev->irq); > + tg3_interrupt (dev->irq, dev, NULL); > + enable_irq(dev->irq); > +} > +#endif > + > static void tg3_reset_task(void *_data) > { > struct tg3 *tp = _data; > @@ -7482,6 +7491,10 @@ static struct pci_dev * __devinit tg3_fi > return peer; > } > > +#ifdef HAVE_POLL_CONTROLLER > +static void tg3_poll_controller(struct net_device *dev); > +#endif This prototype is pointless. > @@ -7632,6 +7645,9 @@ static int __devinit tg3_init_one(struct > dev->watchdog_timeo = TG3_TX_TIMEOUT; > dev->change_mtu = tg3_change_mtu; > dev->irq = pdev->irq; > +#ifdef HAVE_POLL_CONTROLLER > + dev->poll_controller = tg3_poll_controller; > +#endif > > err = tg3_get_invariants(tp); > if (err) { > > _ > > From jgarzik@pobox.com Sat Oct 4 21:17:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Oct 2003 21:17:43 -0700 (PDT) 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 h954H725012053 for ; Sat, 4 Oct 2003 21:17:08 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:36268 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 1A5zSf-0001aV-IS; Sun, 05 Oct 2003 04:21:33 +0100 Message-ID: <3F7F8E26.3080307@pobox.com> Date: Sat, 04 Oct 2003 23:21:10 -0400 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: Keith Owens CC: Matt Mackall , netdev@oss.sgi.com, Andrew Morton Subject: Re: [RFC] [PATCH 2/3] tg3 netpoll hook References: <31674.1065323779@ocs3.intra.ocs.com.au> In-Reply-To: <31674.1065323779@ocs3.intra.ocs.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 540 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 Keith Owens wrote: > On Sat, 04 Oct 2003 23:11:27 -0400, > Jeff Garzik wrote: > >>Matt Mackall wrote: >> >>>Have an opinion on s/->poll_controller/->netpoll/? >> >>I don't like either name, but don't have any better suggestions either, >>besides something extremely verbose like ->process_hw_events(). >> >>"poll_controller" is annoying because (a) it's way too close to NAPI, >>but (b) it's a reasonably accurate description of what it does. >> >>I think "netpoll" is even worse... It describes who calls it, not what >>it does. > > > ->polled_io ? Not too bad... Better than any suggestion of mine, at any rate :) Jeff From wsx@6com.sk Sun Oct 5 02:18:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 02:19:21 -0700 (PDT) Received: from mail.6com.sk (postfix@cement.ksp.edi.fmph.uniba.sk [158.195.16.151] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h959Ik25031377 for ; Sun, 5 Oct 2003 02:18:46 -0700 Received: by mail.6com.sk (Postfix, from userid 501) id 105AD20C22; Sun, 5 Oct 2003 11:18:45 +0200 (CEST) Date: Sun, 5 Oct 2003 11:18:45 +0200 From: Jan Oravec To: "David S. Miller" Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6, sit: set prefix length 64 for link-local addresses Message-ID: <20031005091844.GA23676@wsx.ksp.sk> Reply-To: Jan Oravec References: <20030926175405.GA31498@wsx.ksp.sk> <20030926201953.3dfc67bf.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030926201953.3dfc67bf.davem@redhat.com> User-Agent: Mutt/1.4.1i X-Operating-System: UNIX X-archive-position: 542 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, The mail with the patch was not delivered to netdev ML for some reasons. Resending it.. The function sit_add_v4_addrs() calls ipv6_add_addr() with plen 64 if local endpoint of tunnel is not configured, so I do not see a reason to set plen to 128 if local endpoint is configured. We are running patched kernel in our test-lab for about week and it is working fine. On Fri, Sep 26, 2003 at 08:19:53PM -0700, David S. Miller wrote: > On Fri, 26 Sep 2003 19:54:05 +0200 > Jan Oravec wrote: > > > please apply the following patch. > > > > It sets the prefix length 64 instead of 128 for link-local addresses on sit interfaces. > > I've seen this patch before, and I remember it being rejected > by other ipv6 developers. > > Do the USAGI or other folks remember what is going on here? --- linux/net/ipv6/addrconf.c.orig 2003-09-08 21:50:29.000000000 +0200 +++ linux/net/ipv6/addrconf.c 2003-09-26 19:37:27.000000000 +0200 @@ -1681,7 +1681,7 @@ } if (addr.s6_addr32[3]) { - ifp = ipv6_add_addr(idev, &addr, 128, scope, IFA_F_PERMANENT); + ifp = ipv6_add_addr(idev, &addr, 64, scope, IFA_F_PERMANENT); if (!IS_ERR(ifp)) { spin_lock_bh(&ifp->lock); ifp->flags &= ~IFA_F_TENTATIVE; Best Regards, -- Jan Oravec 6COM s.r.o. http://www.6com.sk From wsx@6com.sk Sun Oct 5 02:21:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 02:21:39 -0700 (PDT) Received: from mail.6com.sk (postfix@cement.ksp.edi.fmph.uniba.sk [158.195.16.151] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h959Kt25031711 for ; Sun, 5 Oct 2003 02:20:55 -0700 Received: by mail.6com.sk (Postfix, from userid 501) id 7ABF120C1F; Sun, 5 Oct 2003 11:06:10 +0200 (CEST) Date: Sun, 5 Oct 2003 11:06:10 +0200 From: Jan Oravec To: netdev@oss.sgi.com, davem@redhat.com Subject: [PATCH] IPv6, mcast: deactivate timers before ipv6_mc_destroy_dev() Message-ID: <20031005090610.GA23600@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: 543 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, the following patch calls ipv6_mc_down(idev) to deactivate timers. If we do not deactivate them, the following may happen: 1) remove last IPv6 address from the interface - mld_ifc_timer may be active, thus referencing idev - addrconf_ifdown() is called (which calls ipv6_mc_destroy_dev()), removing all references to idev except the timer reference - timer expires, mld_ifc_timer_expire() is called, reference to idev is removed, but not tested (__in6_dev_put()) - idev is not removed and it is referencing dev 2) destroy interface - idev's reference to dev never disappears --- linux/net/ipv6/mcast.c.orig 2003-09-28 02:50:53.000000000 +0200 +++ linux/net/ipv6/mcast.c 2003-10-05 10:42:57.535993672 +0200 @@ -2029,6 +2029,9 @@ struct ifmcaddr6 *i; struct in6_addr maddr; + /* Deactivate timers */ + ipv6_mc_down(idev); + /* Delete all-nodes address. */ ipv6_addr_all_nodes(&maddr); Best Regards, -- Jan Oravec 6COM s.r.o. http://www.6com.sk From wsx@6com.sk Sun Oct 5 02:37:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 02:38:09 -0700 (PDT) Received: from mail.6com.sk (postfix@cement.ksp.edi.fmph.uniba.sk [158.195.16.151] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h959bW25000785 for ; Sun, 5 Oct 2003 02:37:32 -0700 Received: by mail.6com.sk (Postfix, from userid 501) id 4962920C1F; Sun, 5 Oct 2003 11:37:31 +0200 (CEST) Date: Sun, 5 Oct 2003 11:37:31 +0200 From: Jan Oravec To: netdev@oss.sgi.com, davem@redhat.com Subject: BUG_ON() while creating/removing ipip interfaces Message-ID: <20031005093731.GA24023@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: 544 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, Assume that we have application 'A' and application 'B': A: cnt=0; while(1) { if_index=create_ipip("name%i", cnt++); listen_on_netlink_and_wait_for_if_destroy(if_index); } B: for i in `seq 0 100` do iptunnel del name$i done 'A' is written in C so it is much faster than 'B'. We run 'A', then 'B' (on linux-2.6.0-test5). Shortly after that this happens: kernel BUG at net/core/dev.c:2912! invalid operand: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010297 EIP is at unregister_netdevice+0x19f/0x1fc eax: 00000001 ebx: 000089f2 ecx: c06b68e0 edx: c0f1c000 esi: c62b1c00 edi: 00000000 ebp: c62b1c00 esp: c0f1de8c ds: 007b es: 007b ss: 0068 Process iptunnel (pid: 8369, threadinfo=c0f1c000 task=c3218100) Stack: 00000025 0000000a c0f1df19 000089f2 ffffffff c04c67e6 c62b1c00 ffffffff 00003878 00000000 0000000a ffffffff 00000004 00000000 00000292 ffffffff ffffffff 00000000 c016ce20 cfef7b2c 000000d0 c0317b87 c0f1df18 3f0e20e8 Call Trace: [] ipip_tunnel_ioctl+0x236/0x440 [] d_alloc+0x20/0x1d0 [] vsprintf+0x27/0x30 [] dev_ifsioc+0x130/0x4b0 [] dev_get+0x21/0x50 [] dev_ioctl+0xe0/0x350 [] sock_ioctl+0x0/0x260 [] sock_ioctl+0x110/0x260 [] sys_ioctl+0x277/0x300 [] syscall_call+0x7/0xb Code: 0f 0b 60 0b 14 e1 62 c0 e9 9c fe ff ff c7 44 24 04 8f 0b 00 I have seen some recent patches for tunnel devices on netdev, but was not able to test it yet. Best Regards, -- Jan Oravec 6COM s.r.o. http://www.6com.sk From ja@ssi.bg Sun Oct 5 03:30:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 03:30:45 -0700 (PDT) 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 h95AN925005526 for ; Sun, 5 Oct 2003 03:23:13 -0700 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.6/8.11.6) with ESMTP id h9599K201576; Sun, 5 Oct 2003 12:09:23 +0300 Date: Sun, 5 Oct 2003 12:09:20 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: "David S. Miller" cc: Rusty Russell , Wensong Zhang , Subject: [2.6 PATCH] ipvs - properly handle non-linear skbs Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1607745702-212897576-1065344960=:1204" X-archive-position: 545 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-212897576-1065344960=:1204 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, Attached is a patch that includes the changes from Rusty about handling non-linear skbs correctly and modified a bit from Wensong Zhang and me. This is a huge patch that changes interfaces for many functions. It looks difficult to split it in parts but if required we can try to do it. It is ready for inclusion. Regards -- Julian Anastasov --1607745702-212897576-1065344960=:1204 Content-Type: APPLICATION/x-gzip; name="nonlinear-test5-1.diff.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Handle non-linear skbs Content-Disposition: attachment; filename="nonlinear-test5-1.diff.gz" H4sICNkjfz8AA25vbmxpbmVhci10ZXN0NS0xLmRpZmYA7Fxrd9vG0f4M/Yq1 c6qSBEnxrotjNbYsuzqxKVWi0uRNclAIWIqIQADBgro09X/vzOziRgC82G7S nvMqjkQuZnZnZ2dnntkLvmKTmSMY/DPZayf6lvOAh+yWezw0I26zwIysGZv6 IYtmHP66rv/geLcsCP1fuBUd7XzFLuRHNjbn/Ii9d7zFI7vjocddFoWcAwU1 kdQ0NyNsz/Ei7tnQBFb+bnytCCx/Pjc9m93zUDi+x3rtIQOCmXM742E7X5nj We7C5mJJNpu7kSlANI2lPycz07vlVzzSuu1ufzhirHXM6OM+A0qPR3tOcD/A XwJ+GffCMIOgbQH5kCog8hF+qiC3/JATfT+lH6ygfwjDKvK4Z3uSD6jbM009 lpTDFRXD2ES+4VhzKX435eqt5YosydRLmfrrmLZppbrPpSpyrW3IZRfM2TYC idnW/TW42Eqz7o1ryW6PUob9FQz2VjJh9dvY6XY6Fdzehvxx7kTbCD+NtlKl 9+v29rCwq0yavEnWczjSlaSOMPEa7L1/C+StLX6AvNPf63b2OgPtF/MbIZz2 za30Pvvw7Mezi++ufj5C9wktuU8MmrJdzjzfa7mOx82QibsbAZTw74MvIuZP STqLZBLoKUH20J+zC3Phsn9cLkT09GcGfwR33TYb+w/sAd3v3Led6RPxYo3M 96A19LooAbhS645Hor1173ag1ilrjcMFM/dKHBa7KSvdAd5yeu0KAsM5BBI2 YL3e0WD/qD9ivU6nv6Prenll1SzffMNaB819puOvb77ZYTvsK1UB+9oU873o KeBQw7Gm7TXYW1CGYSy+/55RMWvsAUPrK5tPYSBATcZ3V8Z3p5dXZ+dj4+T8 zanWeex04b/9HX090QE0rYjG6nlNRbe6pmk/7TAt/s6OwTpHdbbLOo9v3zZL nh7kH2I3e/u9Zq/HdPUXO0uBz5myGujKwEDuOjAva/W4PXoehBCC72rfnl6O jTenr6/fsedoEEfsOZuL2/oLpMSfj+xh5oBh1jr1ZZ28ef3OuPh2UnP5PXeb LAiazAlmTeLHlvS15GCQTTBskfJQm7bPftPo56dMb4iPff2Syel9C52z+c3i 1qAH2L2fdlqaFgStY1kubbuWk+sFCVZBlRdnUxVcvt9WC0WOJUV8lh7Y7q4c 5tLh/49riH3FXcFxXo3PGVnWu7PxOwZT9dX79zS3CgqJNQF1ttvtuux4vs4S HdYqybex0w14Vw3wMvv2Nr9BDWvtpagvANfOlPxerjYYDTAQ+k3eo384anYP mI5/R+Q8Pr5Arr3GTos1tEloeiLww4hRMLV8l824afMQn+7ttBYeOiZph1Ew s0P2GxjYwhPOrQfYHmJVqGmN0Hx4AcUiChfgrCEgAyEUL2aZUkCesjTKliKK lcX0CZ+Ao+6OwJIbKFYAJSBwC/8DkRmI/AbhPxP81wX3LA5QeuozWdsi5ERx amLyoEC750HkFazHav4iChZgpOM3wISfoI52HG7rbWQlW2fnGEAXgIyAjsLq d1d741eTNil0MDxsQhTSB4N9/Ctjj3bvOzarNfijE9Vrcd9SkIJ6bQRBHVXf 0sAvAy2KZghrxu2FyxMmcWfcLCDuNsgAKmtq4jSX+U9Cg6PTIMMtjtqsCTN+ 43bROyxVXhSAxTRYbQNimO1Y0ZLIpP5Gw1JdZ1rJU+iJEsrx0NdViNTS4nSv WqYSXWT4yrRCwjseRmAOIurLosAXQGZVOlorUIYoV1NWQD0joJpWKJQEt/50 mqXIS7tWoWDxqzWqba1LbQMtthIbF54ZGRL4hiuk2HRU0z5aQQnn6glAQgrn n3kJ7f96CS2xmBswXa27lfJtP5IrZoQSQi8Y0ur5sMKc6PGqOaCtsH5taZYm vmy1fTWCnDPbdvxyLa22ky/Z0rrxrq5duQSpZQzNrAEqigAgGp45B19PQ4vf FaVSIlFEiAScCLOWWrk508DYTsgtpJI2pG1o2qQabYX1MG2V+eTkDfmtIyIe 4gLekqxQAkJ4FtBTrD7cbwL2GRwMm91OHKplJUBJPTNuHM+u6LEK1yq2Z6Hy ihi/YrphFKBRIWgNKtmy5jQsr5mGSayACSR4VGDMSpFBL5Ez5zjTJSRa2Ues fOqat4JqQF2P+pSPj3ppRo4pguAu2ot3yxCzhTCF5ZoGwqpb5557VOoAkMPE IW8BNhdRAw10GazES1eKUdxbyhqXA3I8AqRtrTwWZ9WHvZH4WPZp1Gl2+9Cp If2l1DuGp4hOX9DqAsFnbzG/gb4BYISkjPkhQGjZIzPy545lRODgBLc8xbMQ 5i0HORZepAihA1CuMOrM9++wVF8qO2IhB5jrsakJKRgmi5bp/TlickEJnHab 0aoNDDqtAE1OLtpMyiHNPriL0JmXTZtS31SCuxJ9SaVWPGxIG2mgOGoeQVck 7s71Li36pM4t9c1Z9l4bdW1Vz9Z2jMw8bczxwImaLogbZoXDYmp4Y/mUDxsd jJq9DtjgPvztShuEKsEC1XSFiQCNZR3k1pkFCWF+Ulbx+2YBK8SumvoroNYn 4f4qEdYj/d8Z368a4s/U0gZwcIWaKmHgKgVpRdX8R9CLLC9VRmmP4siyJiJr Vcybht9Eg/nQ+1E6iYP+IQKdg34H/qCL4I8QVzw5fjE/GLeFw1YJmWIukifP Bj66mm2nVdqcijVl49GsCL7VFTneNvXony8QQfqVVW0qUlxTcVCg3Ah54JoW L5/Cch44GTcroZuPRPKxb7jca6pyLy33sLy0VTmmTlTDcVZR5mCIy4P6wWA/ RsoZtobqX8hpqikzjcwbl1NK0aCPucwxw76TwLXIUJNV1lDgBQwVd6SBCYtI ugVfJEnkZ4YE5d/R1Sy1goUdGLn17BX4dS2AzqDnEtCsJx0sbyP/FYV7sR0H 9GVLDlw/VWO5P2wewljud+BPZijz4FnBgzAe3aSAXES2y/REZpClPiLlLHiJ TCvJx3pFx+LgludcAfnLYf7m7CuzgMKscbl5v4k0W62xlcQZFVDWpMK0gI+D fTjoYNp12B+qtKsguB3Srv0O2wAlpNFyZfuFNtD4ZCutL9aK/mVqamamcrn9 2iICLyyWHQZmnwDz4Xc9zQgPD8hPHh50m10FxuOk5cHGeAx0xYgxN+84OfuH 0JFus3wBiVik29aLcuIKFCp6660CXSuDkRlMJNefVIuQ3sZ0uAhFq1H+PHB5 tCJIpfrdoRUmx4JiTNyWqzMwb6ot+j3muzZMAPjg8YcmkUEJtFbfYb/lzh5U nt1iN9XP1DmE6nNfa04jfAIjbbeNes0eOF/825VQTBMBZBULz/Wtu9quFbSO 8VNdGYvc18KtuHOZ5gOyoGy4zf7uuC6kwPDrxl94GUTGRMAtZwo6ni48grNU AZICdr55YiizOvihjp2ETWYKUC6H8pDfO/5CuE+MRgS38YJnL8fX799TNdKe BR4ueGAtHJQ67kaC2NyjBLyt9gY3BleZ+Zlzszt63lSwQqwKwuW21WUWYJfX whOwvUN7l6XPXqh0AruX3Z1MIgs65Vx2gjJKo2cvce0B+9M69mZtIG4dOzO3 MXiRpm9y85PR3ictIYHZC/5rvC4Cv3D8cDRw2QMEch3LxIHFwz0QxvDkkjSC yJfEER3rTLTSptI93DSYsloN+/WSoa1hx9nLlwyHt45rzPD4WZVXkk4o0zWd 8Jw/heRkVq/XEYYqd9dRW5nBDBoi85B9R+1FWFZb6np9t1arSUBRx1D9Y6qo nynmlXPVsroNzQcQKZUvWX/BwxMN7ZLPOa3CgWozC3KWKTgjfeHcAnQjGLh7 6JetdsgHzeEApuxBv7mvztfENb51HqkyEaGVge4w8boFEzAFE36biGKlo7YT vwsaP7u4uDyfnBuTk4s6WV5CRdkb21U79ifn47Hx1ji/nhhXp3+rE2SA0Zk6 jwAwfpUeA/E2fIGxQXywrqqzcaEm8AVpbeCOspV9VGaxXjR9nWRrKooF0zeQ KzuwJ+gEIQ+6h+wht0Sa+D85EIyaN/Fgi/Ifqem3sqarJ1+60o4p3rxkWdYa ZduWPIuR9O1ZOYmcObu0KFjPVN/Jd+Q6sLELNP/yhoXOFc8pyOTfzpsWSffs Jeuw3V22ys6UkAk9zVhCqr8aC2q7htLmRi7NLUtHvcloTDLruKpr0lfqWUXK gBafLTnz/uh41t40oOmfG3/1LxN/9Yy4ySq4E6mFcHWCVFVc833EShWhuHxx ojoSf1Ywly4a4yuriq+tdfG1VRYrW/lYmU6kTWMlK42VWW+xIlZmTFuXmxUw x7B6wsPYKowd7WOs8/+ZypYBTuo91GoitQS/NvJ7upYKUO73Ct1I5aj0Y8QJ 1B+RYR1K29zSciCtAqPpv6mN8Ni9bI+69DJL0rOWpP8/ECoBQoNhl3KXwfCg Odz/w4BQCXqpQi7bI6oc3lhGVWuBUBG/lEu2PZ5aIVclEMpspq7GQTD0nwiD YG6vQUFZiv9BEKSGrQoDyQHfAgJJl4n++zMB0JcBFO1yRFEJJ4h+rwwNbOnl lSOvAAPZGLdpJNdLI3k2/v2RkRzUs3EgL5u3pXE8O2/XhvHiRFRRnFA5U+eh aLF42IsXizXNdURkTP3Q4KY1M7gXhU81x7NgelDN8FEYSAO9or91AnnS8wa+ aLVQRDnFEgmBibzzRw3Fhubpf/UQpXqRyHNI8vQHSh6FNGjRs5EaIM5ceBQm gBQLpngWvkEz04UoaESsAQIpFGr7D15t1zDSOuaLiD+Sm8fdm1gaZGF/yW6M 2Y81Kmyxbp0dMZj+xtXk1eXEmJx/ezpW6kThh90uCT8YxcrUdeR8odzvPWpm iT0LHPJtdlLRQH1gxvdYj7RoKCCTjtU2HPVxt3d4eKB2exPFKfWgagy8dkaz SWSamvqBgBpRRW1QEQ81+Db569mV8eH8zfX7U9yxaAOnh67wZYYRy+hhyE1b PsRBwG+I6IhHK+HQJYeWo4fGXXBF/C6uhr5QechdjjAlJqdvTdroXrcmLC/o VqzdyocrVoXV9d5PWBZex0mXuLq4bdDrKlNhDYaXoP1oxkNBNw+oTF5HFEfk tctu/WlasOY6oapqLz7B1sX9XB1Xo+V2xen3F+dgjVc/fHh9/r4mO7B0wQh9 Rny9JE8uV/DRW0hGPEkG3qiszgKmTvet2Nmb5HbF2cmHC5i+/t0ioGt5yeUc 2lFy7BpdC6mz5KcmS1rHC6/e5tbMbzt25kpNNZsqWmIEgbJbnZndE9rwrCXZ B5WRc0G1doejZnfI9C5C5W5+DqZpUmHne/OjKVscq119qLZ6h006SvRUC5D4 jrtPtWfo8gsHapaynQT9lBFTFEy7wkjyGV5pqmeA0iacFMLkdqMMYPon7qfF NHQeIgdLssoCh0M8CUDAMnxtgosuS14HarIbHuF5TcsPnogAJ7ETITR7cn0z AyESlaKUAmyL2/ixzv71L5kkijsJkW9hRKg+Y7lxAKpmUQJq2okqWrJc31Mt LVeP1eWQA/YWNPlkBAvXrZG6cqoiYpYyHy03mKVmx8mS2jL0Txp8Ri3yxwC0 ZuAtM9loh/69e3thvJqcfzg7yTUMFJ/erhxW0gvUJVvLtyOTGYlX87yvr98Z 52NSqiMM8LLSyUrVJuN0yeW9bfU+jAcE+OBN8e0WMGDeDOLgE2LbB4TZQuDA mYj1GBML2+ae+9TywwBcOXgYqJmMMYGzcb4PpkJbuGhJ4EkobBsPsjtZIhT7 bhpymhq15PySRp+kIkqSFSav1TF1WxyvIouI40keeYQCj26n6SURgreko0D4 UhF0YnLKMgKPzLQgHtrIBZaHcyPiALEJ904Zf4TKRVP60P1+szfAoNjFvyos 4n158lGQGi4CPFrN7SNE6012/eZChbY82qk8PmKo3mx3hiR3hGSDKuLjm+uv itHRcTouLn7s/Vy2XhqHBPZS4WS9GAmWl5lKDs3LYwvoqqVQsuH4QmV5m9GL +HA7Y7Y83I6xGityPJmV0UF3GFUAAA9maMuVBrmsxgQgI8kh/EUIuoHvD354 l7zVwHXAPiCLmKIDnZviDk1EHXwnwXDRSwm6ZomsJc9cf4BKmDBt0MuDE82o GWgV60YpTfsXwE6p+d1CqFm4JjiPJ3XXwKNlRKpbVrPLYEBBs7ISuWqR3mEe NdnzoBWfLDpiIrTYnxbt+N/RnxakreWy5/JC/vM5Npd59pP3XB1cHp9d/O36 1ZtaKkm9ybzIn4kaaebHzs/1MlK7hLSLpPoGtQpZa5G0WKuQtbIsKSqvnq5O EcbtjBBl6r3BIDkcwxrx/Y4mBUszHQ/05uxrC1ujCHAvP91ji4AE5DeyxGNZ Eabr5HfkO4UIPOcclmxI5JeNYrVgNkajiwWYxerJY1H2mNE9jZNkdSIVPA7I 0plJW6K6En5cdno7uUBULDNjK0pSo8wxc6nvGJQ1aQ6hKuQZ5ORMeDIoTZaM sTp1XEUjJA00jVf1P0UEVlV9R50Y7fVoLaE3PEjWEnCQxn6qqCmt3ah3S9k8 84qTJGjEbGmQEJDSQJS8Nx0Xg3xbUeyRUqgSNVDJgcL0Y41cenrfZyNydeBP rWlIFrXqotY6Mj6gu+QDPF92jLrahimtqsqvdpC+6ISe3tvvq6RdW2c0hSHz +MPSeKlhkpcO89ajVdmO2oApEGSLYxvKNYAdbR2reUmfaapmSToFhtha9vex 9/3uKLWWXO/rJWpj/+tj3u8cUJrYx2PVw7jfdCsuykXWJH7JKZPMBulb4j5Z Eb6wQ1Ck1j6icsg9wpN4bEkF2UJBhbQAl67A49ickCcFt4ab4hkQl4NvKFEs S7K1QOhktVW2stYlsubX+XnpaalxlvEK4tUreFNjLVhqaqQZC10yz/4AsGgf zwD1mr3Rllj0C59h/jJHmP8ocKlreZSbbrbGeZhxA1mBzF5SWKdGsRlvs9K3 ep19jWvLesEv5Ez5ogABcttg5Any+3BX350Yb40LfFnT1eR0PMlui5WC/5yL WUcoVy6oAwVZx77XKkKWBLBsC4RV/ko9fJibALd3d5O5hAGlBPGUkYsycoVq ni35aKnC08vL2vOrxCeSy/knD3359rFkukj0S/jX8crAGvhWdXCWAsSgc5gE iPyYkwtrbRcNtooFFZEgHweu1kWBYgyAyIeb6t1DdRtj2QEvZ9Dt38vTtsq8 ZRLX/5J+PPoy3lnfqr28Ry+6baa26tItMtpR6gxowXswgFwkdeRqsOJwi6tq McCkXGI5DLaVc//86x/L11I3uwNSOLJfWLkt+lm2gTf/XFdMDWu57stLP/dW zjeO3xpvLs8vsIjWmOiKNJ1kA9VL19O6MXEPIMkOKS8wYXoZN0+0ViaehBW5 yLAIdujlaJhAxqlEZigvJ2Pjenx28upqwmpIgwmE61umW6dqPZU2qkryrRTW r2DYyZB6XbxurQ9Gh82umrjYC6sCNyXMOZeBSwYZ+zlK2XNCEHPiQjac9oV5 OGvnZ35hKsYESQ6weiavAVpqXiaYv3B44vUPF6+urjJP1YZ0cm4n62lR4HTx Ut0G1bIGdTU5f48bsLixTFa4NP11rWh+TI0aLRiC0VhJui6vLXm0LyNq6fmW hIOrV6Wo1NMSyaCk2znIpgb77NI4G19cTwpbHltwZrY8lBS0PTKHaUO5gRNC vLn6YRwf2ZBdCWkVi84sUDHdw5KTms4CBPHLUIa0X43vRNlPAhFu6afvOaNj JnK3rikXrLFUvUEUdz8sc4EnSHAaS36casT1i3+DGYPNLcfm9Cn0gyx7flUm k/a+TNNehCO11EqzGXGKX1awZqFMlpFV+yyWNZpXJyenFxMJNkhloxFttHd7 GZXhlqVBG57X48vTVyd/RR8kENPMeIgbsmxu0i6R9HaQLuxBttBmrdbf/y8F prhPCUxqD4TqfHN6ldTZLDYjl15aJbOkOEf04kzInALZP6QXig57g+ZBJ4mR +IOxMH7ZXW6pPXcKU4UkH+/N+Qt8uUst9xyPtuBd3rJ3sqQ7dBiEgoynKaMJ 0ncDKZJcxuPRxrUMwo63ISFInKeU7xHw76Ze8UUK9fytobg82TKkTqi3dSFW rsl4OyX3DvnG+O2JgRsrxgWMwunl5Id6cgknc6BzJXm5hcqYOvl3e9/a1cax tPtZ/hVjZ4VISCJICMzFOItgiFkbgw+QZL8rO0dLSAPoREiKNDJm7fj97adu fZvpuUjgS/Z2HBuk6el7V1VXPVWlz1dw15FdSOF1sJIaaigjBnzCHQLOOB0/ PVQxD6nP2k3dwuqYHcWejQ/xDWTTq9RcnmEcXAp1dTUa9FgikSr5SCjna43U r+uvVisanOza3ONdUFfp6w7qittXE7gE+vqpzMK0pn30IseieoZEZKqI7IPH ljtbtqQr277NljYLChi8Vdi9KVBRGMxtB6jkFNrvd9EuAlcmZdVkoO4ALir0 Yh0+w47dDhq7/SFBQ2H8u/ADsVmC1nskH9GEnOoCFKgfcVyfkjRLcVEzBtwm eqeR2160toQCDTgSaMnCQOsnFT3hDIC2aq0k1RndfqwaVQnVB683KkY7waNT 8q22CDFjJdPETnL5tUqga8SknFe66p0PAarmrQbtt3vFGpwWeMU0qIzWyJSF K/G9XZucLaAj8tauI3UidEEVwFcTBWT2LH0QSj5lBvNVsCzMeddZeyXHqb1V 4rhabJDheSRTJD4hS4YpsapK9FQJPcA9uANcwQVhMOCo6AQyUtRFRssgIv3l Llv9k1+nUjuibvH9h7sTp392ewsbfzfYf32w/4/zn98ADz852D84P987+5/4 nsMxubGEGw0rBrAzf3X9UYdNfHbI1lgKsTYAuQMahmqvR/gFjvwZdU3N3iO3 1B/CjDgtfZDgBBiI9zVj1Gj+b8MpxjybalkTyEMvrEejOsawQqFRg38oVC8N oMIxd9dX12qtVlDdWN2ora2JxFLan00mTDsZCwf3qMkErU0U470OMssEQa0c X4SiBYNUHsGVMnzfDcMe4cuhmrIT7pelH+VXpdmLIokIzffSVxFnOF7KJESN ec92cM6vwCCWzPse2aNEokdgCx8O3SvF3KlUhGUTYNktjau9o2SJ/ljCP6P4 FIHIAJOCtglZM1pIEiI0cZ/ewOkrwXneSX4LXNvzbZfj1dAreVAsvyN2bGQy MLdwaZFxpSjME2pwm3XyCBMqnAQHVMILjLsWSJw0FrbUcsO4GzpSHmzd6TS8 RYHg6G2A4sgt7HW8hM0ixhn1UZwYI1RX4SjlpvXDDzq4XkotlnLc8Oz6S3yO 5AwE0Xab5OfOMGrfRPAbsIb2m8O/4N/Tw8PzA75W1UupIpN5kBC/lOnNQK+C tHs+73AFXUIHHSVo+3FZxrsIn+u4gQnkl7iF1D0ag3qeiOfCqZRlzev+BUtt CTvBixdBk74m8cMr3li6fhRvbgZ0vxsQHHtXEBlUXzSKCKSH8iGfPU4cMAxe KL2dWzvdO4wA5vZsOWhZcm5cNah27hJVpfWCjKcVE03g073UbeV5sxY8c/hS UP62V/u2V7ExMfWXXoCMsGUk7AqX4gJ9CcgSa+x0/saqurEVX1tLujEHCuMA bDxQGhcls76+WtvcAF7WaqrbNwEg8JZ2G3aGqHPpAEHE7C9yoPm833aGGDM0 GhHCsBMMRjC2u849v48OD1wJnNruH0pXOoTrBlABTOBF+NVZRNV/Nw0G/asw ppOxphlPSEIpgUoWUWl7y56f/ny2f9D+Pz8fnOQXvjh6c9A++Of+wcGrg1e2 esfMf3onqla9Kzl9SC+b7EJQsqnxaoZ6SC7gmIQHRM2egrUIbwFiK/yGZhdZ HtTHt1j/8VRHuOs9w3KC6z561e271ERoSeBcc7AYnflukhyZVrGMtxVNOqq7 7vEvQja6fYtq0HUkadfVkxu4Wg10DYD9P4G9DqzzejiahBo0aNTkDNinuGXu jQS7l1puxSrG3PApGVcy9C1HrBFF59peT3kFmKQZ6IqHOpgfzKHSqOVuERYr zJW3beL1leJvSw6goIxQexDQb3CB4QJHOV9gmwq/rqTrl0gK+RURlejli2Gp OtPIuTdOWeFp/H7NJoJdZzVMAq9/98KXfJmHDSy8L9A3RWJs3JGD4XQ2CSU/ llzOyH1vgncG04f+mK5osyhso3KpXHZSlWDtwsQIMM7yAiaI6vQHVIarfipK f9f2q2CvSDu2gyv3FVa7fdtbUf8/VezLzynYvJE8zR9sRpa8o6lD9YyAicjd XJ4KfXxWifFepxY+jM/oZpb6un3caeNpIUH2BS0RkjtUOKI1tRvN6Lr9wkAJ BdnZ9eA5hSriwcRtYseULYsRRPUU/ic1jZLk9dHjEzdVRFfBjpHvkV0evpqE FC7WROOu5rUptErNcsNQhm46ZaiWRJxHYI2mmPIir8Lhr6/abw4uXp++KkNF LH7a8AJCU8D1aDbooWcu3VvpdBmjC279y9F7nO0R3VqeiUX82U1ncGWbIuVS E82G3wMnYFdaDVD4oJaQ08dhZiVobQDrcyvSBQcIIPK7srIiRwHPCJmf2DWb k83xjAOvw7WF6z1DfOFAdgZdR99ST1Wp1b0KrrrpotXeMseDl8bUMB2my/sq TRkXb6zrtGarxWgHkW6sjs7SaOWahDBV7Kysqc0D9WVIASxrV0zhVYjqVc0t zuidnvoVT0YYylZqgQwgqrwUyliNU8bDBShjNYMyKsclOJ9GsZcy4Ss58224 PFZr6FoToeksk5DG0rgDZQcFEXVfJd5JR3EhZyxXEVn3KyJ9X8/F2UjNU1AZ WYpbDjQBHgsFZNmnx3hQy5SOpx1d2ftRcNnhcxGUjJorblrHYD4WrGFMwW/k /GUyK0vvqLZ+QsNJsdJt29tfu0lr2k6cVtviTpK0VwNsZ5uwNr6OW850RqFD drJkxJw+hSiWOKMZsE3bvCKxX/BHJozSUeIIqwZehu9puRs/JOVu2z0PS6xM ENnp6HCPiMGjSZflQNwDMEewYIenZ7/unb1i22KNNag696idMm1j7TmCsarP m2sKBq0MzpMQj1eoiHo4VS4CIv/jFkOKjXsMWRtehjv3wJfSzdMKfYtxjbxm 6XRT9NwvKvt0tl061xb9KDbohC41pkwNfGriRRSbqVpSjvGFG07UnIRYwXsG kRk8BSjS41E9wLwnh+JWCOe9otPIrFOunurz1mqt0dQ5e3zIZOd+5LJeK2gH EgitGRwiH6frvdbB6suh0cyzJn9JaeHZqFboVYmAY94MlKbTqPSN0lETDa0v 1Xpv/4hZ7eC90MbvvZy+ZhPmch0mEyb1eUtFdMrXCruzOo9a2L57Pk1cNj+6 zjjwTlxCk+zX4hLLRrYfiNTVSWTFdJGj/aFx1O7ApAreE6RFedt5ClXfszYO 5IERhZxR6Wv8emJ9euDh00JLoXTzO090VNkASPTJ0clP2yjsgygbkFMm+Zs8 NQ1oiJcePr9M9xAzBxx5SCQYIvO6iid2/FlTsdYBPvW4m8Ngq5aaIE3B5V1R R2uAwo/SmLuQe+2/Z/GUyxBVp1PyER2yFx9KEgTC1ArRnIuiupuu0s4tUpgI 4qqQBDfqAggTFt6eca9tVyqja4t1uEivkxKjCAThJyohTloxEJBFQWtdCDgO B8ZoGSiknBd4KsApP/ZUnXLegOITGKkE5XTX5Dxg2/jFRDz+9DKodxhPqzHD eAM7O79QSwg7D7/BwcpNVd5jN0EiEzcrEfQP76xwMXDZw1NfULpSPihPDz8V nJeCYvVC9PJXSK5hXpeaUpo0SBst25vGo8fg+zYn1roN5ZanVGrF9oblP+iH FevxcFyswptDl3XPamJ36HLpu0RK8OhkeOk7w4ATYQs9dUR4ZW/kQbs7x7Nx 9Nyk7Bx+nlS7lzh+lvz7wVFK8lWpaWiMB9/RtHSHq3aYu2cyR6g+6Q9nIHhH kw6qy2AJOjijk9vO4JlBayeYOR80j/Imw2RiuNLRFduvrdhUwGIHY4xrh1uB fyeWaWmAJMxKjeuYYnwJ0k8DL5phaD11W+4q5SheH8y3nUF3Nuiwf4fqBWyQ Gt9auFni8mXct9+zH1RfhyOsSYvowtCZRlwFIp1HCIOZhChEdaxecKxBVooN wijhunAzUpVADaQmSI5Ax3VPmBM4yh3CnjlqzwBWDz/5LeNzmsaFInpv636j +Qe2nPtkrwxWnavvXrUNubxllX4baZtqjS1rUqWlm0Ll1Gl9/Ee0HXw7JWq4 +20P1U9EdjmtkJVwl7UcSgmY3E59vWvtYIWyVz0mH7NGJBzoxK7uqtmL89Qt mBQ4qLcLrs+HDFULa1o8U11IKUY6Q60RQ+i/VhvdwtkZhLb8lacQvmLpxsnt ywOOf+3qqpwp2ll4P/pV0lVvv8xC2r0aW91KTEs1ftVztDde1GkWIMVj6Vm1 V3SP4q2cn+xd8GL6y+qz5hYPcvR52V4tpz9f+Bxiir00Nb4w3m1eUN+HxY7R 9Sqma/Bp+1Dfh2u0rTsZU/dlOVU8f/681tiiHHxrtcamq+WCzX+Pd0DFSTik K+nNphgL589ZOOmIfrMXKt2Wq9TyxN7LBCFmaJOqheoyeMRsxVTg4txgjrQ+ 1VaQlB2lIS0wdhV9t+x/1TxnvWrCm8beDETVQrE09NLK3UoWj/tn4NfK3Usw HEKj+qgz78P2HFhipgr8wiStJ3cxWkvpqVxAOHwXjTDHvUMIufbB4Hd2FC66 kIuISKEJP440DUk8IKslpZkEDnnwXQHtIn6Xkbw2fFehgiuMsD1EgExneM9K kdv+9U3EipBB+K6DQaGYKXau8TxERso3Ns1pjSpSFngJTTGhmuIiFa6XqpoT QDwYKEzxOB8HbuwDFfeHD8MUp74/F6Q4DVCMBMyPKQ4CP6iY3ngUXPF/N4KY 9OmlSXdhLPFnxsrmYpAt6/WiGOR8tXHVVhtXvURxPlRvIfhutaz0uS9eNCsa xpsG4nVK/13gvPgK8gMPtjaov/THulsIyntke5l8dijvl4KWleDywa+o0Y9u JqPZ9Q0IMqHcVDlWPqvpZ1MOlY+kbKrAJCSRUqQWtNwCT70kk0ZnKIAp5tYE SYYjfM8VIMW7noowy8kG2C8d3p+OESs4G6PFoAvyAuov4D/gyneIxNIVLAp0 rj4A6OwkCvi7QIwdfdldSPNBalH4/Qb1PR3x/GBJZHQVjIahsqB3LkdQYo3l E64lD62sjTj/AYDlguDsr8jmr8jmj4FsnhPF6/hR2ijez4x9Pjg7a58dl585 /UuB+D17oiJKBc/icL95IdBZ+ONswPjHQQpLtNQsoHDVAIV9x38OTLZ3M3hR xrJDLoTVwyGNovvgdta9Ce6QuSbjvVaAgYZTQSrgzXQcAUWadG7DCOcI+bpc aRJzEjeKx+fEAWyrVGC+zFO20u3vBHM9KnAIHoZzDXhC5oJaeoIY1eHSqFmD zs0eiwn0aRC1caiUtzc1kz+8qlGXQRpcVGvyMMsQz1kCUGUjGDUGpI/iIIrD 7/oT9FewghAiN8bJnY1Z0/QA3GF/uBjssPh7GnX4MNDh/JjDbEVRyRdyrp6u 9yiAYkt1rU7pl0/pU4orfTwKmBxII+lZJkjoQQrCPFTqQQLg6BaKgR5VArwf +9dB1IF71zZbnt/u7f/j4KL9+hQD2A3DPgU2hx05pqM+RERGF0QUzG2Fr+OV CiSd76LgjyE6cdzcBw0KdA//vDo9OA9OTi+QhwxmvTBowh4u/1BxHD3tlCGc PEzdWeyeqEwlsG3w5C+pDuE+svw1C1Wm0S5ZlTq5URLBN1EPIKIzNrD7rcio +Atdznct0isCNZl6BfTgdE85ZnnQTd5o+ILQCFyotQt9sWLj24WM4iD9nlf9 JABXrSaeG9+q3vwk8FbgfyrusokjKyENChGNZFKjnLvAl4P5/AZ6vqqkfmqP NB13qN+gUHvD4Ph0f++4fXTCx/lviRH9hoLRuJ1HbbUkHfsbY0jjAUFT4KRx yTkLTeotWwxMCkf6nUTRN9gSrNMEQI73YOkdJUZVknHea7q4c+4FcKK16Cn9 o1wxk8l9LcDsmLTRo8loZsXkHdVvQP7arsTdcZPIN6TchSFtuTC56vwwuUwt XhbkRl8qbMhNDiLK845QTt6rdHkgHCUJqjML2k8Rs1BSQOSK/hQPkE7aUBjH L3tHx3s/Hh/QkiHMYWsTEzhUG6tNHadbmUrS7yIsDi0YP3XOtx3ciMrlauKi KkaQGzE1KAk+gFJVrXKuz8bquspUOr9/VF/r1UdAZCMgmsi50UDNW03pwNme LUluVlfoz/erlJlX+Uyx9jjvBQ0/+RXZhxN1OXYBoiDLlF5uiqqDzpQDz447 aPA29TAEAeTKaYQ4TYOrnRLXAD6HTeA0oBswXDPYrKC2Rs3UhOp5Um74+658 bvEv1Bp2pv3BvVW5WpStWhOTMK5iessNB3Gj72+wHLd2J0iQKXCLE6gByz0L 3ecWqUHHO82JdJof3XShuKYL3O8ClhyNXSwVT01yqrLAWLnsc15IFdx0Y48W tqpuW4pTg0/7g1I5SSESkraNHvOL1BWNJstLc9u7SU1yi48yUtzi40US3Ga/ x6m/muS1Rz8bzkl8ZcNzOlM0H1qpBTMS+nGuEXUeezcPTKdSsIK5MqrY6VDi j27gVYa7RpeDuE4iJTp/PNtcsueV7eBcT97KigrrkLtprqJx6q6hZxnbhp4v sm9yXsSNs/m8trYVVOFHa0PlRypRpsS1ZrDM7iNWQFEduJlV/8skGtTUJ6D3 QtZcy8e4URs3a+O12rhVG6/XxhsOoIaL/Lbxu9bXiF0W6rm7wSTjZbrPvaBr XXvQRzHCQs9EkyGdZHyKUdMx9jdQ6DEhO2w0PRaoVhmhreRJpYY1VQf1QJrj GpSGumvdQtgxBthz1O+gvRyFCVZYZ/Uo0UZFcrdboJh6w421avuJmzAMxcZc TbxeWlayHA2xSi8wUAj5P88zsh9Sn8HJws9QHdR+uxPw/Fk3Ey6+a69LcizU LEoCXI5buw1v0YlnTOK0cpJiLY+vI6ofWI+nH9zPl7vBd6vfoVzNn1/A563v FDpz/FsfI3zgj2WklFKoju/QlAsg1dQHA/uuRvX1YTOsq4r6uIVMef4S9sds GL4fE/qBdnSnGylLljMhyovIWYnqWIB2pXEDqVIfDSUgZU+i0WxQ1iWAT/GC N1YNt9SLBJ2txPY2VthMqbCxUG1rj1pb61FrW3/U2jYWqw2PSqI6WnD7DOBn 8TQoj1svXjRbleAv+HXtxQuMy46/Nl+82MTfxg0uLknlyuMN9WDdtt82+LZb t4+8UIs+9mvdtorSycRzqfvw29rvphe/NX83/fit8btq8LdVotGmK7+tm2et 3y0Zq+Fg8xtrlMah0VKpF0k2edZsPg8oDgGKJG8702n/XRi8GfWA4L9//75m /x3D9Rv+Vp7xrSr2GImxdeXW0ZDkrdhj6j2I/5fhJBURDJzTBuUbH7nlDgZr Jz11Sqh2f1SROVtIqZwVI1kwY5RD4pKSAd7qLyWyyXJ0w5EKGq1NygXdWF+v rUlQTE8Xhm2G0hLLhsZ/a8KqE/WDVVix/qoF+9fq6irrPjS7h9faQu2wx9hh y3gj+5LEKZECSK+iYkRfzQZ0VUWlxOWgP72hFEawdUBsdJUsnDyGrjMo0sFl uX3ePji/2Pvx+Oj89cEr+zw0NFj2mHC4+lqN5niy5uMVmFUHPXSSRd3sijGM 53hn6dsWK0gDmy8HVpdh5duK9SyZbTLuTN8pgScptWplfuxOR6wmsoFeatFz ktoFLClZAI8I1bJl9Obu4TUPdeVM+SyJRnoVdfokbLuPdNf4sbZamDFewxUa zy0eTpFqTA1WNtzzg7NfDs7gOnh2dPKT9b3IEM7jSh1o9XeV76xiS4gRAALO sqx2pl8SOXYJJVgRyuox6ctbFLZXw5F5GjI6y3BW74WXs2u4TbzdO/8FbZNj 2KtA45w01VBX/WWgQ8q5z2DPRSRZkDmNzuvWRq25hfe9LfzJgjvhH3YDPKTa eS3gcP3ma45uBl9Px0B3o6synMfaM0L02v9biCGsltNfU1VLTaARRERfvtzE D2KbM8/K8rAiT6ExOfS4S6IJ/IKtKvMVqflJzy/+wWiu+XPWx/D2vXAQdeoC cYDD90cYjknvhZG37/k9Uk0LwVDt1IMyrE+d1kqiRmeX0Ep6LmYkaGbu9pcq hSzKBvfQ1fGg06WcTGSwwbRkY+FlKlKeZJEFobc7vi/LBsJ5V72RKWS9qAiJ SrzkUA7BVf/9bbgdKBV/ZzDDOwgaoRUM2EDmdLYlIEXSv7hbAXIY7IbV7tPk S8JZPK+pE6XnMDEgdnR6QvnUbNKm80lKJ9Gln6wblAprWMZ9WrGea/CJPDAi j2Idcc8yVwjyiyTNNZRFqs3WhhFJOFDmdMR2RILwdiNcRyBQfAWxzEt02Cyp AhWw5H9EVRGUaoCZZTJFjP4wS8J4uICRWn+WfPERxAvMSE/kav15bU3MFiam Rgr8Q4QN5suYQBIPoaYMKAT0XTOMuLRYwkP1v0B4UFbSV8QjcDbubkJCsLDT pBAjA0DxiRCpEsRCAgTP+jksTyjaEjHDn769ODo9OVcIR2PA0KklXx8fnEhy O3LbRazsNXRCMPUKETAM1pr1Sxjg7WwQ9eGOBtK++Ih2u7OJTjZJph7FVRgV IDT5Er0hq9jccovXXsgTiR3qcp4nAaULQNnyT7Zmq+o+3XU1Rxt2rCJXEUQi xr8mBPjdqNhsjFAdwpZu8Yo1Giq25BNVrkdRQOIKEEKQP2D2vzVYHphY0Z2Y uXKeOEqutmaxpQQriAm5Ox6hy77echAWpcZTSQKbz+HugrR8awt/moD+OvFo WrZQpAXsmkBUBCvmd51EtHJuEtvDv/4qNZYVFqOxuaPjhxSWeKt5xWXek2Iy bPv946ODkwslJSvh2PkWhWNd/rt/Tb7DgJUjVzROl4xjgnG6XOyKxV6p+PTs IsiSdx0HsWhUUa5kFB6mojmEu7uRcTGK3CN7VC2yiT4qHCgGwxV105JCM7+J nqj8kb6RaBvat9P4gNyPZlg2lAqjocSwVOKzlzZ4r4ucjmdU5D19U6gYOAvy XW3ttyEwMcwdbx7cM/aWMT2pBWwC5Ib15QM2noLzlUyYjezC4kNDEiATv2Qn MUuvBaZ2UkyaTlJG8OYqyn5rrYaCUORIon5BVMBrhSWTHKk0z4I0uBx0U01I /DDDhsQFFjEi5b1JOVUwsGwDM5quqaChbH48xizQ/ei+/iPBHsp3IYYMCIFC HKPTT33fHLMFbJLYtQdaJQtX8Vh2SWqQE02yYdL3XJJZk21mcbulO7ZFLZdY yyRz401yd95k8a2X+aoO/AJ7j35+2r03eYTNV6yOx9x9k7ztN3nE/Td5hA2Y QfZyiN6iJC+X4G2sIRyN/pVkiLSnggfuqQdTs49Ky2rBMrtqGh2OA6sajHBr rIJIOoJdkbeswz9TlxUfZSwrPl5kWbPfI1qCoMrq8y2zrL8K0QgeY32Hfz5w fQtW8EWsLwmKqUssTzNWWUosstC5r5IKfaNFWdjxp+Q0xT+YdPVJHUTBWQ/R aSDZt1mGcyfcSd6cXDEFibmdXuvFm69OwUCnLqUqYIWjcV6x2qc11ya7RnPz 9wzHrkSoW5f+C8H3OAELeN+JgVIcJKjggQWc/m2ff9fl3zZpBM/gFnZx9vPJ /t7FwSsr4CTdPTTUo7jveyVuNKEW0mKgUJwdyT9lQl3OEeakmvbiirxHJezv rVf18FLnkZdqhXR2edGK06c1dfjid6sHkOhs7iAY/50359uxdrep6cBpuu42 oSeeHvB904qe7SnfSy3f+F0tVdrYzK17yrX7B5wszFVTugEc/h/lfxycnbRf Hfz480/BM4w/hxFV8S8p++Cck+2FUayFSHO7k45jNQXyCDQVWphG57yNZLrV wrs6/CuwVvzj47RsM3hS79w4Ogsf5QwyqG5dNAY+ku6hmGwW6Q/JUx8OS6z1 TOodb8jHAqSMU4/VJVPCYdQ8t3DQrQJOP5NSgBUojXGhDZz2zZZYx4rOug69 P/e0J68Zc024ajh9xrMnupQ2xWkzO++ENhpbhIFqNpNTSm4PaiRxAW+eOSy6 a828ZbZGWsSMFlGFSWZB8TT1mhVhDsYyQZKBt7HWxJt6tbG2XmskJoMFMOjf Iwlfc9SULWzZgf9yZKzm+kaG6FRYiGD5YUHx4VOJUd43isoF8wk2H5MbhtN0 gL5VIpcfUqnFGWLO64twRKjygSxxQdocbzj7eC1GnvFZOu8rfVyupwf4ALa3 oKCRaHphxpcqXDwa52uuku9mc622IdNq8b1Aj+RBjK8w5wvUpXlhptVKZVo4 lEfiWvNUlX2ugq986z+Zb5E7bTbj4iK5nIuLLc668t4nrMYmoe42Fe+S48Mb MuAsPgi9ImM42yk4M++/Ybow02jwYYePnYcc0+sP5HQLkuNE0zlnckGSTA8z 2F2SNHNAk1QKzcZbXBNM+8hr8qHABD+E4T14ivNZHsMfciY5e5Yzp3mheX5O kRs2m14uaEb3MDY4Hx+cixEuv/Nl7iWxqVVrNWBoW7V1ZwuZyy0Pz0qr83Fl UMpAo7bMoq2KKyshT+bSYVvOqf1YSFDSmseSCJlYI2fHFG7EyR9zGA9yyNEo 40A57uU8kdzt3irH1ULxHbUjpManpUR4dHojNgGTsy1t2DrISsrI7fR5gj/7 oLCBVlYN9JpzNyLLaLQnHsuuM0ddHpLjIVkxa06uMYcFtrwofZYcF0+9EEjq ha8mnf8wk05WdoFsm040gikILu+jcKoDqFrZ2gyuVccMLWarcSfzAmGR+9vo abTgjPJ7MGA7o4H+iImcHjDn/L2dv4B/l2oXk+h9TJHFXQr306f8WCmeGSqh bMBOk5Lqx0eiTFEvf8zgd9V5ehTryBMVYTKXxmUaPRSBgyWL+rchpnTiWGzy Se4EzDw4G0D75PTszd7x7zsO8S92e4q6eZcnKpF7d6JSi1+dcl6nm1Ojtt6E q1OjtsHah29UhNEXg/5w9v57rOPmZZD4D33HEOcuvhvf229yj+C1+Jdplenq SKoSRMNt5xq2NAUWjPUJqrrqD6Jwgk1UU5+2cVaoF8nOwSTJk2xdnAbvfh7D X7z5z2eH8kA40jmwVU82BkBFYtL4ecqPIyEFVfNuojezPikAcnG/NXQeyTf6 2HCAeLdAzy6AaCWdtNepQFnaa87Dnv2wwU7OdgK6RXqc6FDugGI9jnWqljWc isQy/FD4GHxyS2yi5c+okf4Sz4CaFv+Wyj8Fuccg+xwsehCKdDv9KBQ4C9mH If80uDKV3oWfxIxeL24ArxbrWTHN1Txqm1ScqHUZFOEAf2QelfiNni4a+JY+ M/hBjgxf9F2tkU6r7gamUuEEZYfcD61sXNBTK/YodV8F5MW0nBiUshb4didL y87+NKgtEz8de7wiTVbnaDIjEjk3nYxCXqMZXqFjW7G8OGVXjTD5bbliYgxw NIjl4CjCtGK3krDrLiTPYpjX+wCzsWNiSzFebgXVrec1FQ8C3jyWtOd2vFEM ShsOMLFHh+Jiqy/FG1Le1B5MxhOOM6mnusitWOEYcP+ZKdQbHsHJfcntlFVm qhKoklqLNrMoy6ztJJB3TC6s32IVkjRQpLCbp3XVeJm6q49uX/BahfWdW+jt 1MDAp1u1RtMD58FsjgZJ3MZs9ayHZE/DcpKYLCOJWWsGo0GvP+Zfh+FdHw+8 twb34C7zGfRXoBI2IUOEpxzlAD/Ac/KxYz0nXqHx3kxh7nZh/rBO89nEY6Dc xXi9Kv+vNGYaIvElVkraDP5vsPr+EP5TzAF6JT2AFbMa196BTgmrNxUTqzNB +93s5D4C69D3DJVf8vo9vwa6/u8nOoGFrVhjTVvd0bSxjzBnxuLEgCoePhx4 CgiPUSco1Z/K4UmHjRR3hrGq3OUcWEGq3McA353xeNDvSiDQcDBGP/orSsIF ApWdxOodBYpoY66GESV94QNpx1LE+Ccqzv5NBxMfjS7hYn6vEmzXlE/teNQf UmIjScxcJCF8384HX8KZVO+w3onTTOWutgTzzTa3+dcb2PW/E9xxWdijizfB L0cUbyIRU9ekAmUPZWOJUM6iU5RoYcwYhwKms2hICGmzKjx3mZluJcZXn8Tz vLErNKXmxoRQJrTlOaaAlIQBl+HViAI2DK8pF5YJa0lh6M0QMH45fjUdYCJE 9cmytkjcEMr+EAtlKe0W2pYqCr5/Y9KUx+tXST1wXnBhkBJjelh3gWCPyUTu aGrnO0MSRGSv9/9mnKZOmySsoCFPZXZNaH0KOkKED7kmBdqzMtCjE02AVJ12 hTotfEi8BH8JbQ9jLUgYx2kcu/cN5gn+d4xvND1nEmu8rnVYw5hFaNeyCL3+ lWNkxYuYEienJwc7av305KfXhovoKxavMZE8/moG+0jbiVTAjz6HuCD6YnE2 3CB16TbN/S4fTInmapvo2Cc+UUFC91W2LymWuKcYHdflvUGZfjDXc5iu2Lf0 nEh3STCX0apTJjvZ3JtQjrUixwDZVEVUfAC3qeSgLN98/LWrd1vJXie3bvWY Yvu7MnFsHCx4WWEUMMHbaR3ONirPg9M6FsLcQuXqt72Kyl8MAzPafGtV1EPh IEtl61lFMdrlCq2tziVkarKmQnlR6ZpswcPURCR3J2FyTBNLel+UWFLN7dKD eGcwl9TzeGw2WER++gycOdAiG/le7hoavPPl8mwrGXJpL4rC27FaeOwf0NzB Cj88ijiL9FX/vb0zkAki08VcY9PwT9g7sNGe1Etpkmd/+OkFz6CY5FnizN9Z M8FP55qKaqmULu7IbDyytOPZfgx45VXWAg/l5dVCD2pJ7KfWExUd55NKRBaP 6hWViJLvuBLROyMR9f5bJKKPKORkCVgVI455R2ghj75ECanr232PJSFV85bf mZyiwsiDcHgLWEktoeNhYLxUmSCpl2ZSNr3rY2qG2KFlitTtwHlxztH2fPeC qlvY2XPOjrM5iLPF4p14/eu2IjOFjx93yNJ4x45gYC4YRQCHijgl23fmWPrh UXFbCnDfuBOPExr0WIerGR0WqOATCUabhhj0KHgpDNjmGuXMaTU2RGXu1eAG mPCMlE2RpXidS0b3Anc8x6XypOovG5eQb8S2Q6eL4Dr93nsrXZQpCBsT6fqO FB6GdzyOwA1tun98en6w49TIJ0sPHD//prv0u3LuabU2yS2mtblaa+ioKZRJ nfNnh4FBEk3dSClGaTsnBqo4BGpuBNQc3UkDQBXAP+WRuY9plotrCYFKjvvD 9mAENHkJuRL+RkzZ3fjkaQR/rYlnO0tusSV9WaaW4HITbytw+BY5JTxvoTVr o9EQuDzzsnr4HjPdfIQoLQQX9r/sfsSxokMKdHkFtQfBLpCXZ3CMKPCEyd2+ i3TLCkdIo9ra4rhRKnBUacW4u+AbZvtx7ApdwOxGKObbpFQWrwtkY77sY7IR Kuh8hydjxZ4vaTQ+jbhVE+XkGPlKQ9sKoMfivDTufsnjUfkj2xrgxwOKfw+l PxTF8UGPcnB8VCIXx0elFsfx5bzOYYc4Z+KGittPFDEJ5/sDtnk4QOjb50TV 4Up/Ft/heMNfYFyHTwAyUslBUkBGxeK0cj4AG4ajgt1Yz5IQiR1bVMvCFtkl 8vBFc/Y40aus0fh67IcVZYxJ6XQNQ1LuW61mrQEcqQUHd62Qd7jewp/eOzzR 9JfoHT7X+fGJOB/vIGWA3hY/SaWMM1Ra6PTkdXOh4+PtSi1jCOlHZgMuWGtB 9XnDeMzbPo96l36hnv9FkHMwBqwef+xoGNtHx6wVvQNgt/QBwQ/zQ/PUmfyI oDjs2EcDxbW+guI+EShuo9ZoKlBcaz0TFIcn/2GgOG8N7plcnt3Q7nogKG7m gOKwzk8IitONs5qcVt75mhT3TielQh+Gzuq8ibXx1P4WX3KGqGtLuq/hEnxZ cLtqbpc+h11bb8eex66NX/4N7NrSTW3XZl7itWsreSIGovo72LVz8WgZ9uov GClp2avzR5hphi6EusO9kWmHls20I2WzUHdkUVa2ZtcKHVhLoWzNuPTlmxVD DWkhjNzklOO2Y+Ueaqn28qVM7J6fF/a+YveUpdrhbYtg9+wKPhp2TybdaU3n EY0NwjBoew/OY8yWI5RlzFZFlK3SbephcL9Y84WN2cQD7H7symU9PhFK6Hgw QlDPuwchaKSofISg1b8EQtB6ZtVELLKYUZ706V+eJPXFIQT/KyWphpKk/mMQ gl/hgVnwwIcDAecXwFKBgP9R4pcXKJgjfn0FCibFr48oUeUDBecVsubCFn5h 4lhRbOGnEsceH45IJoDPA0d8UNNWbMAEvbMRPI55IFVg8cMXU1X9eiul6vfj GJ+qXuoVt6MYsisDI5kGkpwPJZkDk4zvXpujOqcm0R/BSy4OmCyKmMyFTBbH TNokIh0/mQRQ+khMprnFLuKgKQvCKbPxlK5xQCEqW020tqw93xJzi19n/OWg /ebozkdD+xUNdgbiV1qsM5r7DQr/sLa1+cUB5qDJJGAOhpMOmIOHkqp3cx0B c63GlgbMTcJrTM87IXF6lwU4+zuqdDaMFcNS7pdewBwW+2yAOby/pULkaKsu BpGbpKdvnWTnbp0smLg1+z1CQtK60r+SsfVsNBv26mcjmHUrT2jh3IqThyZj LVhB6nl3QQOYQrp9E3bgAgYHafnPnTiewE7SmreA07CXuoL0LGMJ6fkia5jz IhnXKQvq5tpHSpcJPXjgmhatoeCixldOJcz0ZcosmCVzmp6EbZqdfm26YOK1 7PcIorq1RY4R9LNhZVQOgnO21LzuTG9QjbTIot48dE2LVbDgkibOKTR3OSOC zvmSH5AP2e75osmQ7zKyId/lpEO+WzQfcs6LFNy+QZlzGx+JFNw9ODVy0Ro+ Hym4y+DTdzmM+m5RTp3zIme+2aT8PfTDEAO9vg9k3HcP5txFa3gskoDtIdwN 5GD8F07/uy5c77AHbdQ85y/1+9t+lLrW/DBjsbnAIqud9yana9qsrWGiI5Ol Ra4SLpKLQ1jzNJOO4s6vQ3FOA0pEk9Ho1qhu3GXFdW2PrZf4vrEctcdWNK1e OIg6qOFW1QUvg8ZG8IOuPtiGz2iLw56pL8sMoKuL3oYreSHaQ1XlarzAX3/R 6AYj6A3VYGV3QFVYO3w/7gx71ArrM/jFamO9svS/jXXKZfDT4dv23sXpm6P9 Cusq5e5WPzg5fXPwhtt0jBc59gqeJ4/JAmfKsliUuWAlqOpfnVj+H+CvucnX P2BHngTf9MIrXGJmYv98c3TBI5tEFbz6/+sJauD/zVoC+FQvCQa024EzEPyF cNL9NsZCb8N17u3B2cX/7HC5k8P269PTf5TfHraPTg4uaog7hUaOT/f3jtun P1+IDoIuQvRCaRLVX85WetMILlfvgJBOCYQynkUVqrJaKottI6/xaoHGqS7T PKo7YciZHQg+BHc3/UEYlGEfBSrj2SZTzI3nchfHeeLA8oS6vHGNCRyKnlKr yxfRaAofzy7aF6fnZfgAnfoQfCBFB9+XVTVG5xOUODNS6QD3yeFsSLy23FgV eGZzdbNG8MxN7cBQKl1jVdH7djiZjCbKgFTXesf+tD0c0WnvTGhu0HCjdVIv doPbaFZh8xmQWjgErEplMKs6RtpSmTiLcPic5a2/hE3LJwmu6NCEfdY0jeGN WOQ17NYkIpiqMsyIXHZwdtY+Oy6LXHZ5P+5MmTiiXDYcBbfh7WhyzzIZvhWb pzoqvKps5gskjJkzBcFl2O3MpqGCJQ9HEVub+0DppmQEJKgVvNy5ihB/hfoB NDqvBEfwfDS+r4+GdTQdhwLM+oGKKyOznlScD9GqkjFaabNxlmyqg7p92z4c mxrLX+KwfX5xenxwwtuhGltbi96I3yZQLYRoI4o2mMDRCDkECB6USYgyUcgv 9aacKkJ9gF4v6XXcIcMlRlmDqbqBCbnpdP/YDjpkwuSsBCFaiEm75xrneT+O YE7bPVSmN8h4+U3/CiY02D89OTz6qQ3H/fDo+OLgjBM1qF4Mr1grw3Q/+Aaa gMnFwHTe17A9OkprlIGz2VB5IvXWoBxo2zJ6ODd/tK86/QEsvPAeUxIV139c TULCCCjO5FmDaukY4dnuea5aBRm2LyyaetfarLXWoXvIv7l/uammXQFoQmrH YHkS7RBTOqNVxRMABFaWZzTl6JPubYjkstR8NBrywSWEw09v0NCLSnnlfw5U pfA9y0PtLBxCcHSFRw6RAMYEz5DHGo1G4I+3HYUQoG/HnXv0IahxHdMR1oGn cBo3l+IveA8mFwCPEXVF9wK2dS0YoV2bm0VaBURt1r0JoHNHb8nKHU6nVBWZ voez28twUuEaCCdwaZnAuVNAS8gQDmsDHLk/7E5CPBgdq48sP8hQsPKBeD+g aNsfCgoUlxOt6vCFZ3wrCogRJ+mWPd+gRuJU28dFlMoen/MTWP8E1WIzlS0w 6Q1Pogt2xwfcYFSRhv68eBE0d57Us+EcguYYRqObKZuOolFE3EQBOySWKkxT PCSS2Qh9vd88IFuNl/DNXxYOx57ROB5H+3eQev5G5Rbzs60PMgjeDcE+NcV9 hq0EjK+LixHxBrRcWVZW1BZgMJT7nuP1MsK9Xod6YB/WqR4dEcoZ9tWgcz0N lkTGBIJ70j5sn5y299+enl3oARtftys4Ae0uVkgAGMdvre7ABDF3GJbG2wMW 2v22R7l4eGkNUoPZnvggRtog7jG4Oj5V48i4HEaWvTU+29Ws7o+F6Rbu9pj6 q/zsONvbBHlou82tXIckmLalAZEdZSNPKwgxI+6w9by2tgbcYX21tibCKbt3 KbHuJUl1BNHp21m+lnyJtF4dGp8tV6IIOHsS8W2eRcrW8+rg/KL988nZwd7+ 6xp9c3i2h5z24NXBK1hWqHhQxg7EltWbG49HjihFJbthZ1XsWJMvLjfVXKGK 0uRlPhKOyMZMhLSGceRdPyoAFVxi9AHvMpsPClLQ6QfOeRwvUFBOTq3rEcW6 +gLTYyP+5hiQyiS3xCheIoIJxsFjowadnnCz+m6m4HD4u3K9QtJrg2KFSsW/ NjS5G6fLOwuCDT9Q35KXrKq3X5p7OL1asrrlWfodJUs7eAR3GvJuA3XrqOE5 azjHdY+uOq9O9i74XPrL6kPpFperxuHRP98cbMOdGyiVh8WGw0Fnch1O7YVF oQc/wga5jm5YGgauRQXRubMzpMdvLn5G5gVb/XqEOxE2WL8bkpgIG1QJYCAz DQZcB76A+NJBeLvCQTz+NjeYtbV1usFsNbSBZ447zMe6xFQDhw5t83Zzr6lx CmzuPa1VymBcXdtoaa3LvPoNjzID6F/bKDRo0tVJVbsfPim6QrDY4PSPzj0w 7tEdeiijnHQHkjtsMwI1k9DEWw61pLBTOtN6f7oiiFoONQHr0kIgzTrGnBAN EvYYXZNhpzh6lBoQs/f6G8tFmIJ9obzNrtMebUh88YIUDUk0A/lukKUh0QrN o5Nf9o53bGSyuaSKF7GnVdZiSIfpbZn3xJ1PWK6zEArpHMhLOuI+IquRgcH9 Sq5cWmRnJpyy1FV9vqy1hqmb3pTTOTN2DqZlGkblJZCN9n8U1eQIZDeiaPJW 7FFFh1JbX0MET6vRxMVnycxD8gPVtyzg8N+DFFW1odTRMfMYPSSDZmmDSFer uaWUL18A5bLJ0NYG6VlbG6tf9awuFelNvupYv+pYi0ko680mHfPNzS/zmK+v rRGLbm0prCstCcW14d1OM0r7PR9a7oBeswCrGU9rVvJwnz63RPrcedS5JaXN VV9yynD4mnOGx0t3sTi2cAEV98ea5Y6GUaePqt67fnQjog9e/blFVxFcArqS qkC21MP866SrmOf6+lZtYzWorjdXa2vPbbI7mkUWxfWqC3E4KEa440TXKeWI CCWrZaUGevGiyeoJpM5pKkOntCseyt0T7yV04qy7Ct01yqQnxsgzv5x/D9ef ioiGimXMr/mpFn/PuQKq9+MsjDa3Jk14EdIaUCJMsETQEJ7PMfxaNjRIRzF5 oL6pml6JM4AFlVf1hyuvqgWqCHLqCFzVleKj/SHNf0xNJQiyVGHDy0PqaTyk nsZDRH/yiRQ6T9hpm9U6ZQcVsrxcWVJZ7UkMmXTtQFZ1+/izAqXbd4+5HHLo FxGAatCoJMwE+LzLqphy17EomAA62Vo8ochpujZZmgtFE2UazekPbtH58hLk HKg3gr0OVXRHkwnFqmKjUThlOI3M/WWIEw+/3sFswmwJqZ8gXkvFtdJSzmPo C2UMh+Q6bdnRCENlbFscKgs63hl0nYtYpt7Nq/VSm5lYmN7QpBVCYY2MGTBW ds+msabs82qO4vIELvHWiJY5VMmyNtcJOzM87kjYWtf4/GQPqWvEeGgPK1Pm JQmLQkaUOioQcEwwoJEYYPS5suIMowzadaAhwV9/BZZfRbIAx5CKx+3pOQkE 92DhyDgoBkzaqrElxEMkjnDs6rW64/26j+4Vt7BxQvK/K5djYK8KM+AaKuwM JSriv2nU+EQfHTWssgzHlI4NKcEaykM+M0S3VKg3HOoztekeRXQOFhKdOaDi ag2EzvUNDcVE+rbtvy1rDyGUkhbTrf1/JvV3+L56AQA= --1607745702-212897576-1065344960=:1204-- From davem@pizda.ninka.net Sun Oct 5 05:24:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 05:24:41 -0700 (PDT) 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 h95CO525017066 for ; Sun, 5 Oct 2003 05:24:05 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id FAA27077; Sun, 5 Oct 2003 05:19:13 -0700 Date: Sun, 5 Oct 2003 05:19:13 -0700 From: "David S. Miller" To: Julian Anastasov Cc: rusty@rustcorp.com.au, wensong@linux-vs.org, netdev@oss.sgi.com Subject: Re: [2.6 PATCH] ipvs - properly handle non-linear skbs Message-Id: <20031005051913.0df50683.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (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: 546 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, 5 Oct 2003 12:09:20 +0300 (EEST) Julian Anastasov wrote: > Attached is a patch that includes the changes from > Rusty about handling non-linear skbs correctly and modified > a bit from Wensong Zhang and me. Patch applied, thanks to everyone for following through on this work. From yoshfuji@linux-ipv6.org Sun Oct 5 05:27:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 05:28:26 -0700 (PDT) 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 h95CRr25017413 for ; Sun, 5 Oct 2003 05:27:53 -0700 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 h95CSkft008590; Sun, 5 Oct 2003 21:28:53 +0900 Date: Sun, 05 Oct 2003 21:28:46 +0900 (JST) Message-Id: <20031005.212846.50858920.yoshfuji@linux-ipv6.org> To: jan.oravec@6com.sk Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] IPv6, sit: set prefix length 64 for link-local addresses From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20031005091844.GA23676@wsx.ksp.sk> References: <20030926175405.GA31498@wsx.ksp.sk> <20030926201953.3dfc67bf.davem@redhat.com> <20031005091844.GA23676@wsx.ksp.sk> 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: 547 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 <20031005091844.GA23676@wsx.ksp.sk> (at Sun, 5 Oct 2003 11:18:45 +0200), Jan Oravec says: > The function sit_add_v4_addrs() calls ipv6_add_addr() with plen 64 if local > endpoint of tunnel is not configured, so I do not see a reason to set plen > to 128 if local endpoint is configured. This patch seems logically wrong. --yoshfuji From wensong@linux-vs.org Sun Oct 5 05:47:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 05:48:09 -0700 (PDT) Received: from lb1.ctrip.com ([218.244.111.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h95ClU25017899 for ; Sun, 5 Oct 2003 05:47:33 -0700 Received: from penguin.linux-vs.org ([211.136.72.123]) by lb1.ctrip.com (8.12.9/8.12.9) with ESMTP id h95Ckb6v031611 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 5 Oct 2003 20:46:58 +0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by penguin.linux-vs.org (8.12.8/8.12.8) with ESMTP id h95CfYeN001962; Sun, 5 Oct 2003 20:42:14 +0800 Date: Sun, 5 Oct 2003 20:41:34 +0800 (CST) From: Wensong Zhang To: "David S. Miller" cc: Rusty Russell , Julian Anastasov , Subject: [2.6 PATCH] ipvs - two additional minor patches Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="-1463755008-1767717351-1065357462=:1942" Content-ID: X-archive-position: 548 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. ---1463755008-1767717351-1065357462=:1942 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi, Here are two additional minor patches for IPVS in the kernel 2.6. The ip_vs_conn_unlock.patch is to fix the unlocking bug in the ip_vs_conn_seq_stop, otherwise listing connections would cause the system lock up. The ip_vs_procfs.patch is to the #ifdef CONFIG_PROC_FS macro for proc file creation/destruction. Please consider to include them. Thanks, Wensong ---1463755008-1767717351-1065357462=:1942 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="ip_vs_conn_unlock.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="ip_vs_conn_unlock.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTM4NiAgLT4gMS4xMzg3IA0KIwlu ZXQvaXB2NC9pcHZzL2lwX3ZzX2Nvbm4uYwkxLjEwICAgIC0+IDEuMTEgICAN CiMNCiMgVGhlIGZvbGxvd2luZyBpcyB0aGUgQml0S2VlcGVyIENoYW5nZVNl dCBMb2cNCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCiMgMDMvMTAvMDQJd2Vuc29uZ0BsaW51eC12cy5vcmcJMS4x Mzg3DQojIFtJUFZTXSBmaXggdGhlIHVubG9ja2luZyBidWcgaW4gdGhlIGlw X3ZzX2Nvbm5fc2VxX3N0b3ANCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCiMNCmRpZmYgLU5ydSBhL25ldC9pcHY0 L2lwdnMvaXBfdnNfY29ubi5jIGIvbmV0L2lwdjQvaXB2cy9pcF92c19jb25u LmMNCi0tLSBhL25ldC9pcHY0L2lwdnMvaXBfdnNfY29ubi5jCVNhdCBPY3Qg IDQgMjI6NTQ6NTggMjAwMw0KKysrIGIvbmV0L2lwdjQvaXB2cy9pcF92c19j b25uLmMJU2F0IE9jdCAgNCAyMjo1NDo1OCAyMDAzDQpAQCAtNjcwLDggKzY3 MCw4IEBADQogew0KIAlzdHJ1Y3QgbGlzdF9oZWFkICpsID0gc2VxLT5wcml2 YXRlOw0KIA0KLQlpZiAobCkgDQotCQljdF9yZWFkX3VubG9jayhsIC0gaXBf dnNfY29ubl90YWIpOw0KKwlpZiAobCkNCisJCWN0X3JlYWRfdW5sb2NrX2Jo KGwgLSBpcF92c19jb25uX3RhYik7DQogfQ0KIA0KIHN0YXRpYyBpbnQgaXBf dnNfY29ubl9zZXFfc2hvdyhzdHJ1Y3Qgc2VxX2ZpbGUgKnNlcSwgdm9pZCAq dikNCg== ---1463755008-1767717351-1065357462=:1942 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="ip_vs_procfs.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="ip_vs_procfs.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTM4NyAgLT4gMS4xMzg4IA0KIwlu ZXQvaXB2NC9pcHZzL2lwX3ZzX2FwcC5jCTEuNyAgICAgLT4gMS44ICAgIA0K IwluZXQvaXB2NC9pcHZzL2lwX3ZzX2N0bC5jCTEuMTAgICAgLT4gMS4xMSAg IA0KIwluZXQvaXB2NC9pcHZzL2lwX3ZzX2Nvbm4uYwkxLjExICAgIC0+IDEu MTIgICANCiMNCiMgVGhlIGZvbGxvd2luZyBpcyB0aGUgQml0S2VlcGVyIENo YW5nZVNldCBMb2cNCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiMgMDMvMTAvMDQJd2Vuc29uZ0BsaW51eC12cy5v cmcJMS4xMzg4DQojIFtJUFZTXSBhZGQgdGhlICNpZmRlZiBDT05GSUdfUFJP Q19GUyBtYWNybyBmb3IgcHJvYyBmaWxlIGNyZWF0aW9uL2Rlc3RydWN0aW9u DQojIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQojDQpkaWZmIC1OcnUgYS9uZXQvaXB2NC9pcHZzL2lwX3ZzX2FwcC5j IGIvbmV0L2lwdjQvaXB2cy9pcF92c19hcHAuYw0KLS0tIGEvbmV0L2lwdjQv aXB2cy9pcF92c19hcHAuYwlTYXQgT2N0ICA0IDIyOjU1OjM0IDIwMDMNCisr KyBiL25ldC9pcHY0L2lwdnMvaXBfdnNfYXBwLmMJU2F0IE9jdCAgNCAyMjo1 NTozNCAyMDAzDQpAQCAtNjUyLDEzICs2NTIsMTcgQEANCiANCiBpbnQgaXBf dnNfYXBwX2luaXQodm9pZCkNCiB7DQorI2lmZGVmIENPTkZJR19QUk9DX0ZT DQogCS8qIHdlIHdpbGwgcmVwbGFjZSBpdCB3aXRoIHByb2NfbmV0X2lwdnNf Y3JlYXRlKCkgc29vbiAqLw0KIAlwcm9jX25ldF9mb3BzX2NyZWF0ZSgiaXBf dnNfYXBwIiwgMCwgJmlwX3ZzX2FwcF9mb3BzKTsNCisjZW5kaWYNCiAJcmV0 dXJuIDA7DQogfQ0KIA0KIA0KIHZvaWQgaXBfdnNfYXBwX2NsZWFudXAodm9p ZCkNCiB7DQorI2lmZGVmIENPTkZJR19QUk9DX0ZTDQogCXByb2NfbmV0X3Jl bW92ZSgiaXBfdnNfYXBwIik7DQorI2VuZGlmDQogfQ0KZGlmZiAtTnJ1IGEv bmV0L2lwdjQvaXB2cy9pcF92c19jb25uLmMgYi9uZXQvaXB2NC9pcHZzL2lw X3ZzX2Nvbm4uYw0KLS0tIGEvbmV0L2lwdjQvaXB2cy9pcF92c19jb25uLmMJ U2F0IE9jdCAgNCAyMjo1NTozNCAyMDAzDQorKysgYi9uZXQvaXB2NC9pcHZz L2lwX3ZzX2Nvbm4uYwlTYXQgT2N0ICA0IDIyOjU1OjM0IDIwMDMNCkBAIC02 MTYsNyArNjE2LDcgQEANCiB7DQogCWludCBpZHg7DQogCXN0cnVjdCBpcF92 c19jb25uICpjcDsNCi0JDQorDQogCWZvcihpZHggPSAwOyBpZHggPCBJUF9W U19DT05OX1RBQl9TSVpFOyBpZHgrKykgew0KIAkJY3RfcmVhZF9sb2NrX2Jo KGlkeCk7DQogCQlsaXN0X2Zvcl9lYWNoX2VudHJ5KGNwLCAmaXBfdnNfY29u bl90YWJbaWR4XSwgY19saXN0KSB7DQpAQCAtNjM0LDcgKzYzNCw3IEBADQog c3RhdGljIHZvaWQgKmlwX3ZzX2Nvbm5fc2VxX3N0YXJ0KHN0cnVjdCBzZXFf ZmlsZSAqc2VxLCBsb2ZmX3QgKnBvcykNCiB7DQogCXNlcS0+cHJpdmF0ZSA9 IE5VTEw7DQotCXJldHVybiAqcG9zID8gaXBfdnNfY29ubl9hcnJheShzZXEs ICpwb3MgLSAxKSA6U0VRX1NUQVJUX1RPS0VOOw0KKwlyZXR1cm4gKnBvcyA/ IGlwX3ZzX2Nvbm5fYXJyYXkoc2VxLCAqcG9zIC0gMSkgOiBTRVFfU1RBUlRf VE9LRU47DQogfQ0KIA0KIHN0YXRpYyB2b2lkICppcF92c19jb25uX3NlcV9u ZXh0KHN0cnVjdCBzZXFfZmlsZSAqc2VxLCB2b2lkICp2LCBsb2ZmX3QgKnBv cykNCkBAIC02NDQsNyArNjQ0LDcgQEANCiAJaW50IGlkeDsNCiANCiAJKysq cG9zOw0KLQlpZiAodiA9PSBTRVFfU1RBUlRfVE9LRU4pIA0KKwlpZiAodiA9 PSBTRVFfU1RBUlRfVE9LRU4pDQogCQlyZXR1cm4gaXBfdnNfY29ubl9hcnJh eShzZXEsIDApOw0KIA0KIAkvKiBtb3JlIG9uIHNhbWUgaGFzaCBjaGFpbj8g Ki8NCkBAIC02NTksNyArNjU5LDcgQEANCiAJCWxpc3RfZm9yX2VhY2hfZW50 cnkoY3AsICZpcF92c19jb25uX3RhYltpZHhdLCBjX2xpc3QpIHsNCiAJCQlz ZXEtPnByaXZhdGUgPSAmaXBfdnNfY29ubl90YWJbaWR4XTsNCiAJCQlyZXR1 cm4gY3A7DQotCQl9CQ0KKwkJfQ0KIAkJY3RfcmVhZF91bmxvY2tfYmgoaWR4 KTsNCiAJfQ0KIAlzZXEtPnByaXZhdGUgPSBOVUxMOw0KQEAgLTY3OSwxOCAr Njc5LDE4IEBADQogDQogCWlmICh2ID09IFNFUV9TVEFSVF9UT0tFTikNCiAJ CXNlcV9wdXRzKHNlcSwNCi0gICAiUHJvIEZyb21JUCAgIEZQcnQgVG9JUCAg ICAgVFBydCBEZXN0SVAgICBEUHJ0IFN0YXRlICAgICAgIEV4cGlyZXNcbiIp Ow0KKwkJCSAiUHJvIEZyb21JUCAgIEZQcnQgVG9JUCAgICAgVFBydCBEZXN0 SVAgICBEUHJ0IFN0YXRlICAgICAgIEV4cGlyZXNcbiIpOw0KIAllbHNlIHsN CiAJCWNvbnN0IHN0cnVjdCBpcF92c19jb25uICpjcCA9IHY7DQogDQogCQlz ZXFfcHJpbnRmKHNlcSwNCi0JCQkiJS0zcyAlMDhYICUwNFggJTA4WCAlMDRY ICUwOFggJTA0WCAlLTExcyAlN2x1XG4iLA0KLQkJCQlpcF92c19wcm90b19u YW1lKGNwLT5wcm90b2NvbCksDQotCQkJCW50b2hsKGNwLT5jYWRkciksIG50 b2hzKGNwLT5jcG9ydCksDQotCQkJCW50b2hsKGNwLT52YWRkciksIG50b2hz KGNwLT52cG9ydCksDQotCQkJCW50b2hsKGNwLT5kYWRkciksIG50b2hzKGNw LT5kcG9ydCksDQotCQkJCWlwX3ZzX3N0YXRlX25hbWUoY3AtPnByb3RvY29s LCBjcC0+c3RhdGUpLA0KLQkJCQkoY3AtPnRpbWVyLmV4cGlyZXMtamlmZmll cykvSFopOw0KKwkJCSAgICIlLTNzICUwOFggJTA0WCAlMDhYICUwNFggJTA4 WCAlMDRYICUtMTFzICU3bHVcbiIsDQorCQkJICAgaXBfdnNfcHJvdG9fbmFt ZShjcC0+cHJvdG9jb2wpLA0KKwkJCSAgIG50b2hsKGNwLT5jYWRkciksIG50 b2hzKGNwLT5jcG9ydCksDQorCQkJICAgbnRvaGwoY3AtPnZhZGRyKSwgbnRv aHMoY3AtPnZwb3J0KSwNCisJCQkgICBudG9obChjcC0+ZGFkZHIpLCBudG9o cyhjcC0+ZHBvcnQpLA0KKwkJCSAgIGlwX3ZzX3N0YXRlX25hbWUoY3AtPnBy b3RvY29sLCBjcC0+c3RhdGUpLA0KKwkJCSAgIChjcC0+dGltZXIuZXhwaXJl cy1qaWZmaWVzKS9IWik7DQogCX0NCiAJcmV0dXJuIDA7DQogfQ0KQEAgLTg4 OCw3ICs4ODgsOSBAQA0KIAkJX19pcF92c19jb25udGJsX2xvY2tfYXJyYXlb aWR4XS5sID0gUldfTE9DS19VTkxPQ0tFRDsNCiAJfQ0KIA0KKyNpZmRlZiBD T05GSUdfUFJPQ19GUw0KIAlwcm9jX25ldF9mb3BzX2NyZWF0ZSgiaXBfdnNf Y29ubiIsIDAsICZpcF92c19jb25uX2ZvcHMpOw0KKyNlbmRpZg0KIA0KIAkv KiBjYWxjdWxhdGUgdGhlIHJhbmRvbSB2YWx1ZSBmb3IgY29ubmVjdGlvbiBo YXNoICovDQogCWdldF9yYW5kb21fYnl0ZXMoJmlwX3ZzX2Nvbm5fcm5kLCBz aXplb2YoaXBfdnNfY29ubl9ybmQpKTsNCkBAIC05MDIsOCArOTA0LDEwIEBA DQogCS8qIGZsdXNoIGFsbCB0aGUgY29ubmVjdGlvbiBlbnRyaWVzIGZpcnN0 ICovDQogCWlwX3ZzX2Nvbm5fZmx1c2goKTsNCiANCisjaWZkZWYgQ09ORklH X1BST0NfRlMNCisJcHJvY19uZXRfcmVtb3ZlKCJpcF92c19jb25uIik7DQor I2VuZGlmDQogCS8qIFJlbGVhc2UgdGhlIGVtcHR5IGNhY2hlICovDQogCWtt ZW1fY2FjaGVfZGVzdHJveShpcF92c19jb25uX2NhY2hlcCk7DQotCXByb2Nf bmV0X3JlbW92ZSgiaXBfdnNfY29ubiIpOw0KIAl2ZnJlZShpcF92c19jb25u X3RhYik7DQogfQ0KZGlmZiAtTnJ1IGEvbmV0L2lwdjQvaXB2cy9pcF92c19j dGwuYyBiL25ldC9pcHY0L2lwdnMvaXBfdnNfY3RsLmMNCi0tLSBhL25ldC9p cHY0L2lwdnMvaXBfdnNfY3RsLmMJU2F0IE9jdCAgNCAyMjo1NTozNCAyMDAz DQorKysgYi9uZXQvaXB2NC9pcHZzL2lwX3ZzX2N0bC5jCVNhdCBPY3QgIDQg MjI6NTU6MzQgMjAwMw0KQEAgLTEyNzYsNyArMTI3Niw3IEBADQogCSAqIEZs dXNoIHRoZSBzZXJ2aWNlIHRhYmxlIGhhc2hlZCBieSBmd21hcmsNCiAJICov DQogCWZvcihpZHggPSAwOyBpZHggPCBJUF9WU19TVkNfVEFCX1NJWkU7IGlk eCsrKSB7DQotCQlsaXN0X2Zvcl9lYWNoX2VudHJ5X3NhZmUoc3ZjLCBueHQs IA0KKwkJbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlKHN2Yywgbnh0LA0KIAkJ CQkJICZpcF92c19zdmNfZndtX3RhYmxlW2lkeF0sIGZfbGlzdCkgew0KIAkJ CXdyaXRlX2xvY2tfYmgoJl9faXBfdnNfc3ZjX2xvY2spOw0KIAkJCWlwX3Zz X3N2Y191bmhhc2goc3ZjKTsNCkBAIC0xNTM1LDcgKzE1MzUsNiBAQA0KIA0K IHN0YXRpYyB2b2lkICppcF92c19pbmZvX3NlcV9zdGFydChzdHJ1Y3Qgc2Vx X2ZpbGUgKnNlcSwgbG9mZl90ICpwb3MpDQogew0KLQ0KIAlyZWFkX2xvY2tf YmgoJl9faXBfdnNfc3ZjX2xvY2spOw0KIAlyZXR1cm4gKnBvcyA/IGlwX3Zz X2luZm9fYXJyYXkoc2VxLCAqcG9zIC0gMSkgOiBTRVFfU1RBUlRfVE9LRU47 DQogfQ0KQEAgLTE1NTAsMTYgKzE1NDksMTUgQEANCiAJKysqcG9zOw0KIAlp ZiAodiA9PSBTRVFfU1RBUlRfVE9LRU4pDQogCQlyZXR1cm4gaXBfdnNfaW5m b19hcnJheShzZXEsMCk7DQotCQ0KKw0KIAlzdmMgPSB2Ow0KIAlpdGVyID0g c2VxLT5wcml2YXRlOw0KLQkNCisNCiAJaWYgKGl0ZXItPnRhYmxlID09IGlw X3ZzX3N2Y190YWJsZSkgew0KIAkJLyogbmV4dCBzZXJ2aWNlIGluIHRhYmxl IGhhc2hlZCBieSBwcm90b2NvbCAqLw0KIAkJaWYgKChlID0gc3ZjLT5zX2xp c3QubmV4dCkgIT0gJmlwX3ZzX3N2Y190YWJsZVtpdGVyLT5idWNrZXRdKQ0K IAkJCXJldHVybiBsaXN0X2VudHJ5KGUsIHN0cnVjdCBpcF92c19zZXJ2aWNl LCBzX2xpc3QpOw0KIA0KLQ0KIAkJd2hpbGUgKCsraXRlci0+YnVja2V0IDwg SVBfVlNfU1ZDX1RBQl9TSVpFKSB7DQogCQkJbGlzdF9mb3JfZWFjaF9lbnRy eShzdmMsJmlwX3ZzX3N2Y190YWJsZVtpdGVyLT5idWNrZXRdLA0KIAkJCQkJ ICAgIHNfbGlzdCkgew0KQEAgLTE1NzYsMTAgKzE1NzQsMTAgQEANCiAJaWYg KChlID0gc3ZjLT5mX2xpc3QubmV4dCkgIT0gJmlwX3ZzX3N2Y19md21fdGFi bGVbaXRlci0+YnVja2V0XSkNCiAJCXJldHVybiBsaXN0X2VudHJ5KGUsIHN0 cnVjdCBpcF92c19zZXJ2aWNlLCBmX2xpc3QpOw0KIA0KLSBzY2FuX2Z3bWFy azoNCisgIHNjYW5fZndtYXJrOg0KIAl3aGlsZSAoKytpdGVyLT5idWNrZXQg PCBJUF9WU19TVkNfVEFCX1NJWkUpIHsNCiAJCWxpc3RfZm9yX2VhY2hfZW50 cnkoc3ZjLCAmaXBfdnNfc3ZjX2Z3bV90YWJsZVtpdGVyLT5idWNrZXRdLA0K LQkJCQkgICAgZl9saXN0KSANCisJCQkJICAgIGZfbGlzdCkNCiAJCQlyZXR1 cm4gc3ZjOw0KIAl9DQogDQpAQCAtMTYwNyw3ICsxNjA1LDcgQEANCiAJCWNv bnN0IHN0cnVjdCBpcF92c19pdGVyICppdGVyID0gc2VxLT5wcml2YXRlOw0K IAkJY29uc3Qgc3RydWN0IGlwX3ZzX2Rlc3QgKmRlc3Q7DQogDQotCQlpZiAo aXRlci0+dGFibGUgPT0gaXBfdnNfc3ZjX3RhYmxlKSANCisJCWlmIChpdGVy LT50YWJsZSA9PSBpcF92c19zdmNfdGFibGUpDQogCQkJc2VxX3ByaW50Zihz ZXEsICIlcyAgJTA4WDolMDRYICVzICIsDQogCQkJCSAgIGlwX3ZzX3Byb3Rv X25hbWUoc3ZjLT5wcm90b2NvbCksDQogCQkJCSAgIG50b2hsKHN2Yy0+YWRk ciksDQpAQCAtMTYyNSw3ICsxNjIzLDcgQEANCiAJCQlzZXFfcHV0YyhzZXEs ICdcbicpOw0KIA0KIAkJbGlzdF9mb3JfZWFjaF9lbnRyeShkZXN0LCAmc3Zj LT5kZXN0aW5hdGlvbnMsIG5fbGlzdCkgew0KLQkJCXNlcV9wcmludGYoc2Vx LCANCisJCQlzZXFfcHJpbnRmKHNlcSwNCiAJCQkJICAgIiAgLT4gJTA4WDol MDRYICAgICAgJS03cyAlLTZkICUtMTBkICUtMTBkXG4iLA0KIAkJCQkgICBu dG9obChkZXN0LT5hZGRyKSwgbnRvaHMoZGVzdC0+cG9ydCksDQogCQkJCSAg IGlwX3ZzX2Z3ZF9uYW1lKGF0b21pY19yZWFkKCZkZXN0LT5jb25uX2ZsYWdz KSksDQpAQCAtMTY4Niw3ICsxNjg0LDcgQEANCiAvKiAgICAgICAgICAgICAg IDAxMjM0NTY3IDAxMjM0NTY3IDAxMjM0NTY3IDAxMjM0NTY3MDEyMzQ1Njcg MDEyMzQ1NjcwMTIzNDU2NyAqLw0KIAlzZXFfcHV0cyhzZXEsDQogCQkgIiAg IFRvdGFsIEluY29taW5nIE91dGdvaW5nICAgICAgICAgSW5jb21pbmcgICAg ICAgICBPdXRnb2luZ1xuIik7DQotCXNlcV9wcmludGYoc2VxLCAJICAgDQor CXNlcV9wcmludGYoc2VxLA0KIAkJICAgIiAgIENvbm5zICBQYWNrZXRzICBQ YWNrZXRzICAgICAgICAgICAgQnl0ZXMgICAgICAgICAgICBCeXRlc1xuIik7 DQogDQogCXNwaW5fbG9ja19iaCgmaXBfdnNfc3RhdHMubG9jayk7DQpAQCAt MjIwNSw4ICsyMjAzLDEwIEBADQogCQlyZXR1cm4gcmV0Ow0KIAl9DQogDQor I2lmZGVmIENPTkZJR19QUk9DX0ZTDQogCXByb2NfbmV0X2ZvcHNfY3JlYXRl KCJpcF92cyIsIDAsICZpcF92c19pbmZvX2ZvcHMpOw0KIAlwcm9jX25ldF9m b3BzX2NyZWF0ZSgiaXBfdnNfc3RhdHMiLDAsICZpcF92c19zdGF0c19mb3Bz KTsNCisjZW5kaWYNCiANCiAJaXB2NF92c190YWJsZS5zeXNjdGxfaGVhZGVy ID0NCiAJCXJlZ2lzdGVyX3N5c2N0bF90YWJsZShpcHY0X3ZzX3RhYmxlLnJv b3RfZGlyLCAwKTsNCkBAIC0yMjQyLDggKzIyNDIsMTAgQEANCiAJZGVsX3Rp bWVyX3N5bmMoJmRlZmVuc2VfdGltZXIpOw0KIAlpcF92c19raWxsX2VzdGlt YXRvcigmaXBfdnNfc3RhdHMpOw0KIAl1bnJlZ2lzdGVyX3N5c2N0bF90YWJs ZShpcHY0X3ZzX3RhYmxlLnN5c2N0bF9oZWFkZXIpOw0KKyNpZmRlZiBDT05G SUdfUFJPQ19GUw0KIAlwcm9jX25ldF9yZW1vdmUoImlwX3ZzX3N0YXRzIik7 DQogCXByb2NfbmV0X3JlbW92ZSgiaXBfdnMiKTsNCisjZW5kaWYNCiAJbmZf dW5yZWdpc3Rlcl9zb2Nrb3B0KCZpcF92c19zb2Nrb3B0cyk7DQogCUxlYXZl RnVuY3Rpb24oMik7DQogfQ0K ---1463755008-1767717351-1065357462=:1942-- From chas@cmf.nrl.navy.mil Sun Oct 5 05:53:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 05:53:42 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h95Cr325018280 for ; Sun, 5 Oct 2003 05:53:03 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id h95CqvkT022363; Sun, 5 Oct 2003 08:52:57 -0400 (EDT) Message-Id: <200310051252.h95CqvkT022363@ginger.cmf.nrl.navy.mil> To: Mitchell Blank Jr cc: "David S. Miller" , netdev@oss.sgi.com Reply-To: chas3@users.sourceforge.net Subject: Re: [RFC] add rtnl semaphore to linux-atm In-reply-to: Your message of "Sat, 04 Oct 2003 12:42:42 PDT." <20031004194242.GC94203@gaz.sfgoth.com> Date: Sun, 05 Oct 2003 08:52:58 -0400 From: chas williams X-Spam-Score: () hits=-6.8 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 549 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev In message <20031004194242.GC94203@gaz.sfgoth.com>,Mitchell Blank Jr writes: >Agreed. I'm not sure if it's a giant win (since atm devices are pretty >unique) but you seem pretty gung-ho about converting it so I'll trust >you on it. well if you ignore the sysfs and notifier handling provided by netdevice and rtnetlink then no you dont really gain anything. but i can see a use for both of these things. like to watching the carrier status of an atm card. >Well that might be true in the tree. I think as more DSL adpaters are >supported this will change. The atm_dev->open() is really the only sane >place currently to kick-off DSL negotiation (so the link is brought up >when pppd or whatever is started) i am not sure the negotiation should be handled by the kernel. we will cross this bridge when we get there. i dont see a rush of people trying to add dsl drivers. in fact, the community seems to be pretty stingy with documentation about the dsl hardware. >> people who use ATM_ITF_ANY are going to pay a penalty >Exactly - its a userspace problem. so the idea is to fix it minimally. people who use it should be encouraged to change. i would either get rid of completely or make it work as before. not change the way it works. >I can't speak for all the cards but at least lanai.c has to sleep in >->close() due to hardware issues. Each VCC has its own cell buffers >allocated which the card DMAs into. When you close a vcc you need to >wait for an internal RX queue to drain before you can safely free the >buffer or you might end up scribbling on random memory. right. the he has the same problem. however, you should be sleeping in close. the vcc/sk should have a count of the outstanding skb's (i.e. loaned to the card). the he sends an interrupt when its done with a skb so you drop the refcount on the vcc/sk. when this reaches 0 the vcc/sk they go away and you dont have a problem. no sleeping in the vcc->close() since the removal of all outstanding skb's would be handled asychronously. currently this is impossible since the skb's coming in to the atm card's are typically owned by other layer. (which sort of explains vcc->pop()). > 2. Given the rather spotty history of ATM drivers and SMP I'd rather > keep the driver API as safe as possible. Basically the driver > should only have to worry about locking when dealing with the > rx/tx paths (and there are still lots of problems there I think) > Everything else can be safely serialized by the ATM layer i dont believe any of the smp problems have come from open/close/change_qos. almost all smp problems can be traced to a lack of locking on the appropriate data structures and the improper handling of skb's in the tx/rx paths. (and YOU CANT SLEEP IN SEND!) smp actually seems to be pretty stable now (however we do have a local 2.4 tree that is more 2.6 as far as atm). 2-way, 4-way, 128-way (this one has 4 adapters with a preliminary version of load-balancing). these hosts are atm only. >Unfortunately the flag is currently managed by the driver instead of the >ATM layer. If you're willing to strip out all of the ATM_VF_* use inside >of the drivers then yes we can use that flag. i believe that was the plan. >This is just a matter of adding an efficient API for searching for vpi/vci's >(as we recently discussed on l-a-g) If that was done then we could get rid >of the duplicated data strucutres that exist in most of the drivers (and >get rid of a whole class of races in the rx paths) well the linear seach is already fairly efficient for most people since most people dont have more than a handful of vcc's open at a time. my machine is pure atm and typically i only have about 12 vcc's open at a time. >I don't think that's the case at all - you could safely remove the vcc from >the list at ->close time (but not free its memory until the last reference >disappears) Then an ->open would see the vpi/vci as free immediately (which >should be safe) not sure about this. the fore200e seems to have a problem with reopening on a vcc while there still might be outstanding skb's on a vcc from a previos open/close. From wsx@6com.sk Sun Oct 5 06:16:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 06:17:10 -0700 (PDT) Received: from mail.6com.sk (postfix@cement.ksp.edi.fmph.uniba.sk [158.195.16.151] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h95DGP25018794 for ; Sun, 5 Oct 2003 06:16:26 -0700 Received: by mail.6com.sk (Postfix, from userid 501) id AC59820C1F; Sun, 5 Oct 2003 14:35:36 +0200 (CEST) Date: Sun, 5 Oct 2003 14:35:36 +0200 From: Jan Oravec To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] IPv6, sit: set prefix length 64 for link-local addresses Message-ID: <20031005123536.GA24311@wsx.ksp.sk> Reply-To: Jan Oravec References: <20030926175405.GA31498@wsx.ksp.sk> <20030926201953.3dfc67bf.davem@redhat.com> <20031005091844.GA23676@wsx.ksp.sk> <20031005.212846.50858920.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031005.212846.50858920.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.4.1i X-Operating-System: UNIX X-archive-position: 550 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 On Sun, Oct 05, 2003 at 09:28:46PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > In article <20031005091844.GA23676@wsx.ksp.sk> (at Sun, 5 Oct 2003 11:18:45 +0200), Jan Oravec says: > > > The function sit_add_v4_addrs() calls ipv6_add_addr() with plen 64 if local > > endpoint of tunnel is not configured, so I do not see a reason to set plen > > to 128 if local endpoint is configured. > > This patch seems logically wrong. You mean the text above (current kernel implementation) or the patch which sets it to 64 in both cases? If the patch is wrong, can you explain why? Jan From davem@pizda.ninka.net Sun Oct 5 07:44:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 07:44:55 -0700 (PDT) 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 h95EiJ25019791 for ; Sun, 5 Oct 2003 07:44:19 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id HAA27451; Sun, 5 Oct 2003 07:39:31 -0700 Date: Sun, 5 Oct 2003 07:39:31 -0700 From: "David S. Miller" To: Wensong Zhang Cc: rusty@rustcorp.com.au, ja@ssi.bg, netdev@oss.sgi.com Subject: Re: [2.6 PATCH] ipvs - two additional minor patches Message-Id: <20031005073931.783bf673.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (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: 551 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, 5 Oct 2003 20:41:34 +0800 (CST) Wensong Zhang wrote: > Here are two additional minor patches for IPVS in the kernel 2.6. I'll apply these, thanks. From davem@pizda.ninka.net Sun Oct 5 07:55:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 07:56:20 -0700 (PDT) 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 h95Etj25020206 for ; Sun, 5 Oct 2003 07:55:46 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id HAA27476; Sun, 5 Oct 2003 07:50:59 -0700 Date: Sun, 5 Oct 2003 07:50:58 -0700 From: "David S. Miller" To: Wensong Zhang Cc: rusty@rustcorp.com.au, ja@ssi.bg, netdev@oss.sgi.com Subject: Re: [2.6 PATCH] ipvs - two additional minor patches Message-Id: <20031005075058.70532394.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (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: 552 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, 5 Oct 2003 20:41:34 +0800 (CST) Wensong Zhang wrote: > The ip_vs_procfs.patch is to the #ifdef CONFIG_PROC_FS macro for proc file > creation/destruction. I'm not applying this patch, it is completely not needed. linux/proc_fs.h defines two versions of these interfaces based upon whether CONFIG_PROC_FS is defined or not, when it is not defined calling the interfaces is a nop. In this way we don't have to litter the sources with tons of ifdefs like your patch was adding. From kevin@pheared.net Sun Oct 5 10:01:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 10:02:31 -0700 (PDT) Received: from taurus.lunarpages.com (taurus.lunarpages.com [64.235.234.121]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h95H1v25024353 for ; Sun, 5 Oct 2003 10:01:57 -0700 Received: from adsl-138-88-55-141.ba-dsg.net ([138.88.55.141] helo=ganon ident=kevin) by taurus.lunarpages.com with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1A6CGq-0008OF-DB; Sun, 05 Oct 2003 10:02:12 -0700 Date: Sun, 5 Oct 2003 13:01:54 -0400 From: Kevin Dwyer To: netdev@oss.sgi.com Cc: linux-ha@lists.linux-ha.org Subject: Strange UDP binding behavior (SO_BINDTODEVICE) Message-Id: <20031005130154.5bd9d182.kevin@pheared.net> X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Sun__5_Oct_2003_13_01_54_-0400_MiYcidPLlDoJFbX=" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - taurus.lunarpages.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - pheared.net X-archive-position: 553 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kevin@pheared.net Precedence: bulk X-list: netdev --Signature=_Sun__5_Oct_2003_13_01_54_-0400_MiYcidPLlDoJFbX= Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hello, We have come across something that may be a bug, unless this behavior was intentional. The problem can be simulated by creating a socket, setting SO_BINDTODEVICE, and binding to a port. Then, in a separate process we attempt to bind to the same port but without the SO_BINDTODEVICE option. The expected behavior is to get EINVAL because the port is already bound by a prior call. However, it succeeds, and the second process steals the first process' packets. The likely code in question resides in net/ipv4/udp.c: for (sk2 = udp_hash[snum & (UDP_HTABLE_SIZE - 1)]; sk2 != NULL; sk2 = sk2->next) { if (sk2->num == snum && sk2 != sk && sk2->bound_dev_if == sk->bound_dev_if && (!sk2->rcv_saddr || !sk->rcv_saddr || sk2->rcv_saddr == sk->rcv_saddr) && (!sk2->reuse || !sk->reuse)) goto fail; } The condition (sk2->bound_dev_if == sk->bound_dev_if) will fail because sk2->bound_dev_if will be the ifindex of the interface we bound to, and sk->bound_dev_if will be 0, since we didn't bind to a specific interface. Lars Ellenberg suggests something like: | (!sk2->bound_dev_if || | !sk->bound_dev_if || | sk2->bound_dev_if == sk->bound_dev_if) && Which on its face appears to clear the bug. I don't see any obvious downsides to it either, but this is why I'm here. So, is this intentional or a bug? Thanks. -- - kpd "If at first you don't succeed, redefine success." - Anonymous --Signature=_Sun__5_Oct_2003_13_01_54_-0400_MiYcidPLlDoJFbX= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/gE6CN4rbBhHCVDkRAhq0AKC8qufYmGQ20xqb9wTJteA8P6QFbQCfXVav QPuNUevzS/kGILqDOPuF8sY= =GFnq -----END PGP SIGNATURE----- --Signature=_Sun__5_Oct_2003_13_01_54_-0400_MiYcidPLlDoJFbX=-- From willy@w.ods.org Sun Oct 5 15:28:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 15:29:23 -0700 (PDT) Received: from www.home.local (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h95MSf25017001 for ; Sun, 5 Oct 2003 15:28:42 -0700 Received: from alpha.home.local (alpha [10.0.1.2]) by www.home.local (8.12.1/8.12.1) with ESMTP id h95MSKkW006153; Mon, 6 Oct 2003 00:28:20 +0200 Received: from pcw.home.local (pcw [10.0.3.1]) by alpha.home.local (8.12.4/8.12.1) with ESMTP id h95MSJJe028247; Mon, 6 Oct 2003 00:28:19 +0200 Received: (from willy@localhost) by pcw.home.local (8.10.2/8.10.2) id h95MSHD02577; Mon, 6 Oct 2003 00:28:17 +0200 Date: Mon, 6 Oct 2003 00:28:17 +0200 From: Willy TARREAU To: Jay Vosburgh , shmulik.hen@intel.com, "Chad N. Tindel" , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, Jeff Garzik , "Noam, Amir" , "Mendelson, Tsippy" , "Noam, Marom" Subject: Re: [Bonding-announce] [PATCH SET][bonding] cleanup Message-ID: <20031005222817.GA2527@pcw.home.local> References: <200309252011.53960.shmulik.hen@intel.com> <200309251733.h8PHXWpV013559@death.ibm.com> <20030925211259.GA59653@calma.pair.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030925211259.GA59653@calma.pair.com> User-Agent: Mutt/1.4i X-archive-position: 554 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Hi ! On Thu, Sep 25, 2003 at 05:13:00PM -0400, Chad N. Tindel wrote: > I was specifically told by David Miller that we are not to break binary > compatibility within a 2.4 release. Such things had to wait until 2.5 > or later. We can not require a user to upgrade their ifenslave within a 2.4 > series kernel just to keep using the same functionality they were using in > 2.4.1. I strongly agree. I have been facing this problem and it was really a pain. I used the last bonding version which didn't define the ABI version, together with the associated ifenslave, but when the need to upgrade to plain 2.4.22 came in, I had the surprize of getting a non-working bonding because this intermediate ifenslave. Well, I upgraded it to latest version, which prevents me from downgrading to the previous kernel because it has ABIv2 with no version, so the newer ifenslave thinks it's an ABIv1. So the result is a symlink with two versions of ifenslave on the disk, just in case I have to downgrade. Although I agree it's clearly my fault and I should have been more careful, I prefer to warn everyone about the consequences this might have on production systems. Schmulik has done quite a great job here, and I believe most of it should be integrated, but we have to carefully test each combination of old/new ifenslave with old/new driver if we don't want to break some setups or prevent admins from downgrading if something goes wrong. Cheers, Willy From rusty@samba.org Sun Oct 5 17:02:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 17:02:59 -0700 (PDT) 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 h9602Q25025160 for ; Sun, 5 Oct 2003 17:02:26 -0700 Received: by lists.samba.org (Postfix, from userid 590) id AF7642C0A7; Mon, 6 Oct 2003 00:02:25 +0000 (GMT) From: Rusty Russell To: Julian Anastasov Cc: "David S. Miller" , Wensong Zhang , netdev@oss.sgi.com Subject: Re: [2.6 PATCH] ipvs - properly handle non-linear skbs In-reply-to: Your message of "Sun, 05 Oct 2003 12:09:20 +0300." Date: Mon, 06 Oct 2003 07:42:09 +1000 Message-Id: <20031006000225.AF7642C0A7@lists.samba.org> X-archive-position: 555 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 you write: > Hello, > > Attached is a patch that includes the changes from > Rusty about handling non-linear skbs correctly and modified > a bit from Wensong Zhang and me. This is a huge patch that changes > interfaces for many functions. It looks difficult to split it in > parts but if required we can try to do it. It is ready for > inclusion. Hi Julian! I diffed our two patches. Is see you still use iph temp vars: fair enough: I removed mine after some subtle bugs (although it does make the code a bit uglier). Looks really good. Could you just clarify a couple of things for me please? @@ -527,10 +528,7 @@ struct ip_vs_conn { struct ip_vs_dest *dest; /* real server */ atomic_t in_pkts; /* incoming packet counter */ - /* packet transmitter for different forwarding methods. If it - mangles the packet, it must return NF_DROP or NF_STOLEN, otherwise - this must be changed to a sk_buff **. - */ + /* packet transmitter for different forwarding methods */ int (*packet_xmit)(struct sk_buff *skb, struct ip_vs_conn *cp, struct ip_vs_protocol *pp); This comment is still true: the skb pointer from the caller is useless, so xmit *must* return NF_DROP or NF_STOLEN. I thought about making it return void and the callers always return NF_STOLEN, but there was enough change already. You might want to put a comment in there. ip_vs_make_skb_writable(): how is this different from skb_ip_make_writable(), except you have to maintain it yourself? The advantage of the general one is that Dave looks after it for us 8) In ip_vs_out_icmp(): /* Is the embedded protocol header present? */ if (unlikely(ciph.frag_off & __constant_htons(IP_OFFSET) && - /* FIXME: Remove minhlen, and surely dont_defrag - * test is backwards? --RR */ (pp->minhlen || pp->dont_defrag))) return NF_ACCEPT; If the protocol says "don't defrag" they never see fragmented packets. AFAICT, minhlen and dont_defrag are now the same everywhere (minhlen is not respected: protocols are expected to catch skb_copy_bits failing on their own, and they do). Perhaps drop minhlen altogether, and just keep dont_defrag? Hey, thanks for doing the hard work for me! Cheers, Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. From tgr@reeler.org Sun Oct 5 17:26:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 17:27:18 -0700 (PDT) Received: from rei.rakuen (dclient217-162-65-211.hispeed.ch [217.162.65.211]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h960Qg25025828 for ; Sun, 5 Oct 2003 17:26:43 -0700 Received: by reeler.org id 1A6JCd-0002eW-00 ; Mon, 06 Oct 2003 02:26:19 +0200 Date: Mon, 6 Oct 2003 02:26:19 +0200 From: Thomas Graf To: davem@redhat.com, kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com Subject: [RFC] nfmark modify extension to classifiers Message-ID: <20031006002619.GC11250@rei.reeler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 556 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Hello The netfilter mark field is heavly used nowadays to communicate between tc, netfilter and ip rule. Classifiers are not yet capable of modifying the nfmark field. However it would make sense, especially in ingress context. Example: $TC filter add dev $DEV parent 10:0 protocol ip prio 10 u32 match ip protocol 6 0xff nfmark 0x10 flowid 10:12 ^^^^^^^^^^^ Would set nfmark=0x10 for all icmp packets. Applications (examples): - Differentiate source classifier if multiple classifiers classify into a single class (match again with cls_fw.c). - Mark packets in ingress and reuse nfmark in ip rules if netfilter is too slow. - Use rsvp(6)/route/tcindex capabilities in netfilter/ip rule. Below is a patch to the u32 classifier adding this extension. It would be easy to do the same for other classifiers. (I also have a patch against tc if someone is interested.) The ifdef mess cannot be avoided unless nfmark in skbuff is freed from its ifdefs. Regards -- Thomas GRAF # 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.1495 -> 1.1496 # include/linux/pkt_cls.h 1.2 -> 1.3 # net/sched/cls_u32.c 1.8 -> 1.9 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/10/06 tgraf@suug.ch 1.1496 # This changeset extends the u32 classifier to change the netfilter mark if the filter matches. # -------------------------------------------- # diff -Nru a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h --- a/include/linux/pkt_cls.h Mon Oct 6 03:37:58 2003 +++ b/include/linux/pkt_cls.h Mon Oct 6 03:37:58 2003 @@ -48,6 +48,7 @@ TCA_U32_LINK, TCA_U32_DIVISOR, TCA_U32_SEL, + TCA_U32_NFMARK, TCA_U32_POLICE, }; diff -Nru a/net/sched/cls_u32.c b/net/sched/cls_u32.c --- a/net/sched/cls_u32.c Mon Oct 6 03:37:58 2003 +++ b/net/sched/cls_u32.c Mon Oct 6 03:37:58 2003 @@ -62,6 +62,9 @@ struct tcf_police *police; #endif struct tcf_result res; +#ifdef CONFIG_NETFILTER + unsigned long nfmark; +#endif struct tc_u_hnode *ht_down; struct tc_u32_sel sel; }; @@ -129,6 +132,10 @@ check_terminal: if (n->sel.flags&TC_U32_TERMINAL) { *res = n->res; +#ifdef CONFIG_NETFILTER + if (n->nfmark) + skb->nfmark = n->nfmark; +#endif #ifdef CONFIG_NET_CLS_POLICE if (n->police) { int pol_res = tcf_police(skb, n->police); @@ -470,6 +477,10 @@ if (cl) q->ops->cl_ops->unbind_tcf(q, cl); } +#ifdef CONFIG_NETFILTER + if (tb[TCA_U32_NFMARK-1]) + n->nfmark = *(u32*)RTA_DATA(tb[TCA_U32_NFMARK-1]); +#endif #ifdef CONFIG_NET_CLS_POLICE if (tb[TCA_U32_POLICE-1]) { struct tcf_police *police = tcf_police_locate(tb[TCA_U32_POLICE-1], est); @@ -654,6 +665,10 @@ } if (n->res.classid) RTA_PUT(skb, TCA_U32_CLASSID, 4, &n->res.classid); +#ifdef CONFIG_NETFILTER + if (n->nfmark) + RTA_PUT(skb, TCA_U32_NFMARK, 4, &n->nfmark); +#endif if (n->ht_down) RTA_PUT(skb, TCA_U32_LINK, 4, &n->ht_down->handle); #ifdef CONFIG_NET_CLS_POLICE From rddunlap@osdl.org Sun Oct 5 20:48:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 20:48:36 -0700 (PDT) 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 h963m225031359 for ; Sun, 5 Oct 2003 20:48:02 -0700 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 h963lu131988; Sun, 5 Oct 2003 20:47:56 -0700 Date: Sun, 5 Oct 2003 20:39:06 -0700 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH] janitor: sched_timeout() sets curr_state (net/) Message-Id: <20031005203906.2eadaac4.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: 557 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 Hi, Please apply to 2.6.0-test6-current. -- ~Randy From: Alexey Dobriyan linux-260-test6-kj1-rddunlap/net/atm/resources.c | 1 - linux-260-test6-kj1-rddunlap/net/bluetooth/hci_core.c | 1 - linux-260-test6-kj1-rddunlap/net/ipv4/ipvs/ip_vs_sync.c | 2 -- linux-260-test6-kj1-rddunlap/net/sunrpc/svcsock.c | 1 - 4 files changed, 5 deletions(-) diff -puN net/atm/resources.c~net_all_taskrun net/atm/resources.c --- linux-260-test6-kj1/net/atm/resources.c~net_all_taskrun 2003-09-29 17:34:55.000000000 -0700 +++ linux-260-test6-kj1-rddunlap/net/atm/resources.c 2003-09-29 17:34:55.000000000 -0700 @@ -139,7 +139,6 @@ void atm_dev_deregister(struct atm_dev * while (atomic_read(&dev->refcnt) != 1) { current->state = TASK_INTERRUPTIBLE; schedule_timeout(HZ / 4); - current->state = TASK_RUNNING; if ((jiffies - warning_time) > 10 * HZ) { printk(KERN_EMERG "atm_dev_deregister: waiting for " "dev %d to become free. Usage count = %d\n", diff -puN net/bluetooth/hci_core.c~net_all_taskrun net/bluetooth/hci_core.c --- linux-260-test6-kj1/net/bluetooth/hci_core.c~net_all_taskrun 2003-09-29 17:34:55.000000000 -0700 +++ linux-260-test6-kj1-rddunlap/net/bluetooth/hci_core.c 2003-09-29 17:34:55.000000000 -0700 @@ -161,7 +161,6 @@ static int __hci_request(struct hci_dev req(hdev, opt); schedule_timeout(timeout); - set_current_state(TASK_RUNNING); remove_wait_queue(&hdev->req_wait_q, &wait); if (signal_pending(current)) diff -puN net/ipv4/ipvs/ip_vs_sync.c~net_all_taskrun net/ipv4/ipvs/ip_vs_sync.c --- linux-260-test6-kj1/net/ipv4/ipvs/ip_vs_sync.c~net_all_taskrun 2003-09-29 17:34:55.000000000 -0700 +++ linux-260-test6-kj1-rddunlap/net/ipv4/ipvs/ip_vs_sync.c 2003-09-29 17:34:55.000000000 -0700 @@ -669,7 +669,6 @@ static void sync_master_loop(void) __set_current_state(TASK_INTERRUPTIBLE); schedule_timeout(HZ); - __set_current_state(TASK_RUNNING); } /* clean up the sync_buff queue */ @@ -728,7 +727,6 @@ static void sync_backup_loop(void) __set_current_state(TASK_INTERRUPTIBLE); schedule_timeout(HZ); - __set_current_state(TASK_RUNNING); } /* release the sending multicast socket */ diff -puN net/sunrpc/svcsock.c~net_all_taskrun net/sunrpc/svcsock.c --- linux-260-test6-kj1/net/sunrpc/svcsock.c~net_all_taskrun 2003-09-29 17:34:55.000000000 -0700 +++ linux-260-test6-kj1-rddunlap/net/sunrpc/svcsock.c 2003-09-29 17:34:55.000000000 -0700 @@ -1151,7 +1151,6 @@ svc_recv(struct svc_serv *serv, struct s if (!p) { set_current_state(TASK_UNINTERRUPTIBLE); schedule_timeout(HZ/2); - current->state = TASK_RUNNING; continue; } rqstp->rq_argpages[rqstp->rq_arghi++] = p; _ From rddunlap@osdl.org Sun Oct 5 20:48:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 20:48:36 -0700 (PDT) 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 h963m325031360 for ; Sun, 5 Oct 2003 20:48:03 -0700 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 h963lv131992; Sun, 5 Oct 2003 20:47:57 -0700 Date: Sun, 5 Oct 2003 20:40:27 -0700 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: kas@fi.muni.cz Subject: [PATCH] janitor: sched_timeout() sets curr_state (cosa) Message-Id: <20031005204027.182a0188.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: 558 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 Hi, Please apply to 2.6.0-test6-current. -- ~Randy From: Alexey Dobriyan linux-260-test6-kj1-rddunlap/drivers/net/wan/cosa.c | 2 -- 1 files changed, 2 deletions(-) diff -puN drivers/net/wan/cosa.c~net_wan_taskrun drivers/net/wan/cosa.c --- linux-260-test6-kj1/drivers/net/wan/cosa.c~net_wan_taskrun 2003-09-29 17:35:07.000000000 -0700 +++ linux-260-test6-kj1-rddunlap/drivers/net/wan/cosa.c 2003-09-29 17:35:07.000000000 -0700 @@ -519,7 +519,6 @@ static int cosa_probe(int base, int irq, current->state = TASK_INTERRUPTIBLE; cosa_putstatus(cosa, SR_TX_INT_ENA); schedule_timeout(30); - current->state = TASK_RUNNING; irq = probe_irq_off(irqs); /* Disable all IRQs from the card */ cosa_putstatus(cosa, 0); @@ -1532,7 +1531,6 @@ static int cosa_reset_and_read_id(struct #ifdef MODULE current->state = TASK_INTERRUPTIBLE; schedule_timeout(HZ/2); - current->state = TASK_RUNNING; #else udelay(5*100000); #endif _ From rddunlap@osdl.org Sun Oct 5 20:48:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 20:48:36 -0700 (PDT) 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 h963lx25031358 for ; Sun, 5 Oct 2003 20:47:59 -0700 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 h963lr131924; Sun, 5 Oct 2003 20:47:53 -0700 Date: Sun, 5 Oct 2003 20:34:25 -0700 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: chas@cmf.nrl.navy.mil Subject: [PATCH] janitor: sched_timeout() sets curr_state (atm) Message-Id: <20031005203425.5e474ccd.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: 557 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 Hi, Please apply to 2.6.0-test6-current. -- ~Randy From: Alexey Dobriyan linux-260-test6-kj1-rddunlap/drivers/atm/he.c | 1 - 1 files changed, 1 deletion(-) diff -puN drivers/atm/he.c~atm_he_taskrun drivers/atm/he.c --- linux-260-test6-kj1/drivers/atm/he.c~atm_he_taskrun 2003-09-29 17:32:02.000000000 -0700 +++ linux-260-test6-kj1-rddunlap/drivers/atm/he.c 2003-09-29 17:32:02.000000000 -0700 @@ -2633,7 +2633,6 @@ he_close(struct atm_vcc *vcc) (retry < MAX_RETRY)) { set_current_state(TASK_UNINTERRUPTIBLE); (void) schedule_timeout(sleep); - set_current_state(TASK_RUNNING); if (sleep < HZ) sleep = sleep * 2; _ From vinay.nallamothu@gsecone.com Sun Oct 5 21:52:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Oct 2003 21:52:36 -0700 (PDT) Received: from gateway.gsecone.com ([61.95.227.64]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h964px25001864 for ; Sun, 5 Oct 2003 21:52:01 -0700 Received: from vinay.gsecone.com (vinay.gsecone.com [192.168.1.15]) by gateway.gsecone.com (8.12.8/8.12.8) with ESMTP id h95EBh0J004444; Sun, 5 Oct 2003 19:41:45 +0530 Subject: Re: [PATCH 2.6.0-test6][X25] timer cleanup From: Vinay K Nallamothu To: "David S. Miller" Cc: akpm@osdl.org, netdev@oss.sgi.com, LKML In-Reply-To: <20031002013620.6d8b6f10.davem@redhat.com> References: <1065018387.7194.336.camel@lima.royalchallenge.com> <20031001155623.06b89258.akpm@osdl.org> <1065078208.4340.3.camel@lima.royalchallenge.com> <20031002013620.6d8b6f10.davem@redhat.com> Content-Type: text/plain Organization: Global Security One Message-Id: <1065362979.4370.34.camel@lima.royalchallenge.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sun, 05 Oct 2003 19:39:39 +0530 Content-Transfer-Encoding: 7bit X-archive-position: 559 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vinay.nallamothu@gsecone.com Precedence: bulk X-list: netdev Hi Dave, On Thu, 2003-10-02 at 14:06, David S. Miller wrote: > Please find a way to at least minimally test the protocols > you are changing then, or find someone else who can. I have tested the patch using LAPB over Ethernet (I do not have real hardware) under linux-2.6.0-test5-uml1 and it works fine for me. I used the x25_utils available at http://www.baty.hanse.de/linux-x25/utils/x25_utils-2.3.93.tar.gz and have been successfully able to run X.25 telnet application. I have updated the patch to fix a locking bug in x25_accept I encountered while testing. Thanks Vinay 1. Replace del_timer, mod_timer sequences with mod_timer. 2. Add missing lock_sock/release_sock in x25_accept af_x25.c | 15 +++++++++------ x25_link.c | 16 ++++++---------- x25_timer.c | 47 +++++++++++++++-------------------------------- 3 files changed, 30 insertions(+), 48 deletions(-) diff -urN linux-2.6.0-test6/net/x25/af_x25.c linux-2.6.0-test6-nvk/net/x25/af_x25.c --- linux-2.6.0-test6/net/x25/af_x25.c 2003-09-09 11:12:07.000000000 +0530 +++ linux-2.6.0-test6-nvk/net/x25/af_x25.c 2003-10-05 19:23:45.000000000 +0530 @@ -345,10 +345,8 @@ if (atomic_read(&sk->sk_wmem_alloc) || atomic_read(&sk->sk_rmem_alloc)) { /* Defer: outstanding buffers */ - init_timer(&sk->sk_timer); sk->sk_timer.expires = jiffies + 10 * HZ; sk->sk_timer.function = x25_destroy_timer; - sk->sk_timer.data = (unsigned long)sk; add_timer(&sk->sk_timer); } else { /* drop last reference so sock_put will free */ @@ -463,6 +461,8 @@ goto out; } +void x25_init_timers(struct sock *sk); + static int x25_create(struct socket *sock, int protocol) { struct sock *sk; @@ -481,7 +481,7 @@ sock_init_data(sock, sk); sk_set_owner(sk, THIS_MODULE); - init_timer(&x25->timer); + x25_init_timers(sk); sock->ops = &x25_proto_ops; sk->sk_protocol = protocol; @@ -537,7 +537,7 @@ x25->facilities = ox25->facilities; x25->qbitincl = ox25->qbitincl; - init_timer(&x25->timer); + x25_init_timers(sk); out: return sk; } @@ -760,13 +760,14 @@ if (sk->sk_type != SOCK_SEQPACKET) goto out; + lock_sock(sk); rc = x25_wait_for_data(sk, sk->sk_rcvtimeo); if (rc) - goto out; + goto out2; skb = skb_dequeue(&sk->sk_receive_queue); rc = -EINVAL; if (!skb->sk) - goto out; + goto out2; newsk = skb->sk; newsk->sk_pair = NULL; newsk->sk_socket = newsock; @@ -779,6 +780,8 @@ newsock->sk = newsk; newsock->state = SS_CONNECTED; rc = 0; +out2: + release_sock(sk); out: return rc; } diff -urN linux-2.6.0-test6/net/x25/x25_link.c linux-2.6.0-test6-nvk/net/x25/x25_link.c --- linux-2.6.0-test6/net/x25/x25_link.c 2003-09-09 11:12:07.000000000 +0530 +++ linux-2.6.0-test6-nvk/net/x25/x25_link.c 2003-10-01 19:50:04.000000000 +0530 @@ -51,15 +51,9 @@ /* * Linux set/reset timer routines */ -static void x25_start_t20timer(struct x25_neigh *nb) +static inline void x25_start_t20timer(struct x25_neigh *nb) { - del_timer(&nb->t20timer); - - nb->t20timer.data = (unsigned long)nb; - nb->t20timer.function = &x25_t20timer_expiry; - nb->t20timer.expires = jiffies + nb->t20; - - add_timer(&nb->t20timer); + mod_timer(&nb->t20timer, jiffies + nb->t20); } static void x25_t20timer_expiry(unsigned long param) @@ -71,12 +65,12 @@ x25_start_t20timer(nb); } -static void x25_stop_t20timer(struct x25_neigh *nb) +static inline void x25_stop_t20timer(struct x25_neigh *nb) { del_timer(&nb->t20timer); } -static int x25_t20timer_pending(struct x25_neigh *nb) +static inline int x25_t20timer_pending(struct x25_neigh *nb) { return timer_pending(&nb->t20timer); } @@ -291,6 +285,8 @@ skb_queue_head_init(&nb->queue); init_timer(&nb->t20timer); + nb->t20timer.data = (unsigned long)nb; + nb->t20timer.function = &x25_t20timer_expiry; dev_hold(dev); nb->dev = dev; diff -urN linux-2.6.0-test6/net/x25/x25_timer.c linux-2.6.0-test6-nvk/net/x25/x25_timer.c --- linux-2.6.0-test6/net/x25/x25_timer.c 2003-09-09 11:12:07.000000000 +0530 +++ linux-2.6.0-test6-nvk/net/x25/x25_timer.c 2003-10-01 19:50:04.000000000 +0530 @@ -43,15 +43,22 @@ static void x25_heartbeat_expiry(unsigned long); static void x25_timer_expiry(unsigned long); -void x25_start_heartbeat(struct sock *sk) +void x25_init_timers(struct sock *sk) { - del_timer(&sk->sk_timer); + struct x25_opt *x25 = x25_sk(sk); + init_timer(&x25->timer); + x25->timer.data = (unsigned long)sk; + x25->timer.function = &x25_timer_expiry; + + /* initialized by sock_init_data */ sk->sk_timer.data = (unsigned long)sk; sk->sk_timer.function = &x25_heartbeat_expiry; - sk->sk_timer.expires = jiffies + 5 * HZ; +} - add_timer(&sk->sk_timer); +void x25_start_heartbeat(struct sock *sk) +{ + mod_timer(&sk->sk_timer, jiffies + 5 * HZ); } void x25_stop_heartbeat(struct sock *sk) @@ -63,52 +70,28 @@ { struct x25_opt *x25 = x25_sk(sk); - del_timer(&x25->timer); - - x25->timer.data = (unsigned long)sk; - x25->timer.function = &x25_timer_expiry; - x25->timer.expires = jiffies + x25->t2; - - add_timer(&x25->timer); + mod_timer(&x25->timer, jiffies + x25->t2); } void x25_start_t21timer(struct sock *sk) { struct x25_opt *x25 = x25_sk(sk); - del_timer(&x25->timer); - - x25->timer.data = (unsigned long)sk; - x25->timer.function = &x25_timer_expiry; - x25->timer.expires = jiffies + x25->t21; - - add_timer(&x25->timer); + mod_timer(&x25->timer, jiffies + x25->t21); } void x25_start_t22timer(struct sock *sk) { struct x25_opt *x25 = x25_sk(sk); - del_timer(&x25->timer); - - x25->timer.data = (unsigned long)sk; - x25->timer.function = &x25_timer_expiry; - x25->timer.expires = jiffies + x25->t22; - - add_timer(&x25->timer); + mod_timer(&x25->timer, jiffies + x25->t22); } void x25_start_t23timer(struct sock *sk) { struct x25_opt *x25 = x25_sk(sk); - del_timer(&x25->timer); - - x25->timer.data = (unsigned long)sk; - x25->timer.function = &x25_timer_expiry; - x25->timer.expires = jiffies + x25->t23; - - add_timer(&x25->timer); + mod_timer(&x25->timer, jiffies + x25->t23); } void x25_stop_timer(struct sock *sk) From mitch@sfgoth.com Mon Oct 6 02:03:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Oct 2003 02:03:49 -0700 (PDT) Received: from gaz.sfgoth.com ([63.205.85.133]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9693B25020611 for ; Mon, 6 Oct 2003 02:03:11 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.9p1/8.12.9) with ESMTP id h96935ob007392; Mon, 6 Oct 2003 02:03:05 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.9p1/8.12.6/Submit) id h96934nl007391; Mon, 6 Oct 2003 02:03:04 -0700 (PDT) (envelope-from mitch) Date: Mon, 6 Oct 2003 02:03:04 -0700 From: Mitchell Blank Jr To: chas williams Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [RFC] add rtnl semaphore to linux-atm Message-ID: <20031006090304.GD4651@gaz.sfgoth.com> References: <20031004194242.GC94203@gaz.sfgoth.com> <200310051252.h95CqvkT022363@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310051252.h95CqvkT022363@ginger.cmf.nrl.navy.mil> User-Agent: Mutt/1.4.1i X-archive-position: 560 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev chas williams wrote: > i am not sure the negotiation should be handled by the kernel. > we will cross this bridge when we get there. i dont see a > rush of people trying to add dsl drivers. in fact, the > community seems to be pretty stingy with documentation about > the dsl hardware. Yeah, I've been trying to get that resolved but so far noone is anwering my emails. There are two DSL drivers in some state of completion that could be merged if the companies involved to just release them. > >> people who use ATM_ITF_ANY are going to pay a penalty > >Exactly - its a userspace problem. > > so the idea is to fix it minimally. people who use it should be > encouraged to change. i would either get rid of completely or > make it work as before. not change the way it works. I don't think there are any current users that would be broken by a "just pick the first interface" policy. I just don't want to entirely remove it in case someone is using '*.0.50' in their clip configs or something. There are no users inside the atm tools that need ATM_ITF_ANY. Anyone using it directly in a PVC address is already broken and non-determanistic if they have more than one interface, so I'm not worried if the semantics in that case are only 90% identical instead of 100% > i dont believe any of the smp problems have come from open/close/change_qos. I doubt many crashes happen there (in practice mostly those operations will be serialized by userland - it's rare to have multiple threads opening/closing vccs at once) but that doesn't mean that races aren't hiding. Again, there's zero performance implication to serializing them so we might as well make the driver API a little more foolproof. > well the linear seach is already fairly efficient for most people since > most people dont have more than a handful of vcc's open at a time. Yes, but the worst-case is unacceptable. There are at least some people who have used the code to terminate VCCs coming from DSL customers (a project like that is actually what got me started with hacking on linux-atm 5 years ago :-). They could have hundreds of VCCs active at once. > >I don't think that's the case at all - you could safely remove the vcc from > >the list at ->close time (but not free its memory until the last reference > >disappears) Then an ->open would see the vpi/vci as free immediately (which > >should be safe) > > not sure about this. the fore200e seems to have a problem with > reopening on a vcc while there still might be outstanding skb's on a > vcc from a previos open/close. Hmmmm... ok. I really believe that we need to sleep in close until the VCC is truly free. If userland can't do a close followed immediately by an open on the same vci then something is busted. -Mitch From ja@ssi.bg Mon Oct 6 03:24:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Oct 2003 03:25:23 -0700 (PDT) Received: from l.himel.bg (IDENT:root@unamed.infotel.bg [212.39.68.18] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h96AOh25028066 for ; Mon, 6 Oct 2003 03:24:44 -0700 Received: from linux.himel.bg (IDENT:ja@linux.himel.bg [127.0.0.1]) by l.himel.bg (8.11.6/8.9.3) with ESMTP id h96ANGv04842; Mon, 6 Oct 2003 13:23:16 +0300 Date: Mon, 6 Oct 2003 13:23:16 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@l To: Rusty Russell cc: "David S. Miller" , Wensong Zhang , Subject: Re: [2.6 PATCH] ipvs - properly handle non-linear skbs In-Reply-To: <20031006000225.AF7642C0A7@lists.samba.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 561 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 Hello, On Mon, 6 Oct 2003, Rusty Russell wrote: > I diffed our two patches. Is see you still use iph temp vars: > fair enough: I removed mine after some subtle bugs (although it does > make the code a bit uglier). > > Looks really good. Could you just clarify a couple of things for me please? > > @@ -527,10 +528,7 @@ struct ip_vs_conn { > struct ip_vs_dest *dest; /* real server */ > atomic_t in_pkts; /* incoming packet counter */ > > - /* packet transmitter for different forwarding methods. If it > - mangles the packet, it must return NF_DROP or NF_STOLEN, otherwise > - this must be changed to a sk_buff **. > - */ > + /* packet transmitter for different forwarding methods */ > int (*packet_xmit)(struct sk_buff *skb, struct ip_vs_conn *cp, > struct ip_vs_protocol *pp); > > This comment is still true: the skb pointer from the caller is > useless, so xmit *must* return NF_DROP or NF_STOLEN. I thought about > making it return void and the callers always return NF_STOLEN, but > there was enough change already. You might want to put a comment in > there. My merging mistake, your comment is valid. In this way is better, sometimes we want to return NF_STOLEN, sometimes NF_DROP. But it is true that it can be only NF_STOLEN. I made some changes to return NF_DROP if possible, may be someone wants to log later these packets as dropped ones. > ip_vs_make_skb_writable(): how is this different from > skb_ip_make_writable(), except you have to maintain it yourself? The > advantage of the general one is that Dave looks after it for us 8) The main difference is that we should not call skb_copy for cloned skbs, this is a waste of CPU for allocating new skb. May be you will change skb_ip_make_writable :) > In ip_vs_out_icmp(): > > /* Is the embedded protocol header present? */ > if (unlikely(ciph.frag_off & __constant_htons(IP_OFFSET) && > - /* FIXME: Remove minhlen, and surely dont_defrag > - * test is backwards? --RR */ > (pp->minhlen || pp->dont_defrag))) > return NF_ACCEPT; > > If the protocol says "don't defrag" they never see fragmented packets. The semantic is: Do not defrag for me, I do not care for my protocol header, you can give me fragmented skbs. This is true for now for AH and ESP because we treat these protocols like slave ones, i.e. UDP 500->500 is a master connection and we forward AH/ESP according to the main connection ignoring any protocol headers and payloads. But I'm not sure how that will change in the feature. > AFAICT, minhlen and dont_defrag are now the same everywhere (minhlen > is not respected: protocols are expected to catch skb_copy_bits > failing on their own, and they do). Perhaps drop minhlen altogether, > and just keep dont_defrag? Yes, I forgot it. We have to remove minhlen and minhlen_icmp. It must be: && pp->dont_defrag > Hey, thanks for doing the hard work for me! np, tonight I'll cleanup these things and may be other missed ones. > Cheers, > Rusty. > -- > Anyone who quotes me in their sig is an idiot. -- Rusty Russell. Regards -- Julian Anastasov From wensong@linux-vs.org Mon Oct 6 04:56:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Oct 2003 04:57:00 -0700 (PDT) Received: from lb1.ctrip.com ([218.244.111.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h96BuL25005884 for ; Mon, 6 Oct 2003 04:56:23 -0700 Received: from penguin.linux-vs.org ([211.136.72.124]) by lb1.ctrip.com (8.12.9/8.12.9) with ESMTP id h96Btx6v026767 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 6 Oct 2003 19:56: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 h96Bsn00003085; Mon, 6 Oct 2003 19:54:58 +0800 Date: Mon, 6 Oct 2003 19:54:49 +0800 (CST) From: Wensong Zhang To: "David S. Miller" cc: rusty@rustcorp.com.au, , Subject: Re: [2.6 PATCH] ipvs - two additional minor patches In-Reply-To: <20031005075058.70532394.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 562 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 On Sun, 5 Oct 2003, David S. Miller wrote: > On Sun, 5 Oct 2003 20:41:34 +0800 (CST) > Wensong Zhang wrote: > > > The ip_vs_procfs.patch is to the #ifdef CONFIG_PROC_FS macro for proc file > > creation/destruction. > > I'm not applying this patch, it is completely not needed. > > linux/proc_fs.h defines two versions of these interfaces based > upon whether CONFIG_PROC_FS is defined or not, when it is not > defined calling the interfaces is a nop. > > In this way we don't have to litter the sources with tons of > ifdefs like your patch was adding. > I see. Sorry for the trouble. Regards, Wensong From vandrove@vc.cvut.cz Mon Oct 6 07:03:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Oct 2003 07:03:57 -0700 (PDT) Received: from vana.vc.cvut.cz (root@vana.vc.cvut.cz [147.32.240.58]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h96E3M25009577 for ; Mon, 6 Oct 2003 07:03:23 -0700 Received: from vana.vc.cvut.cz (smmsp@localhost [127.0.0.1]) by vana.vc.cvut.cz (8.12.10/8.12.10/Debian-4) with ESMTP id h96E3Kwk026875; Mon, 6 Oct 2003 16:03:20 +0200 Received: (from root@localhost) by vana.vc.cvut.cz (8.12.10/8.12.10/Debian-4) id h96E3K9H026872; Mon, 6 Oct 2003 16:03:20 +0200 Date: Mon, 6 Oct 2003 16:03:20 +0200 From: Petr Vandrovec To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] Deadlock on ip_mc_list->lock Message-ID: <20031006140320.GB24082@vana.vc.cvut.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-archive-position: 563 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vandrove@vc.cvut.cz Precedence: bulk X-list: netdev Hi Dave, for past few days I'm getting reproducible complaint from net/ipv4/igmp.c:159, saying that it attempts to lock spinlock which was already locked at net/ipv4/igmp.c:1388. It happens when slp daemon goes down on system shutdown. Currently this 'return -EINVAL' below is one I suspect from being guilty, as it looks to me like that nobody is unlocking spinlock & bh in this case, and so system dies horrible death after this (saying that userspace scheduled while in_atomic:1). I do not know why it now fails with -EINVAL while it worked in the past (I see no igmp.c changes between test6 and current bk, yet test6 worked while current bk does not), but it might be caused by slpd update, and not by something in the kernel. Thanks, Petr Vandrovec vandrove@vc.cvut.cz diff -urN linux-2.6.0-test6-c1451.dist/net/ipv4/igmp.c linux-2.6.0-test6-c1451/net/ipv4/igmp.c --- linux-2.6.0-test6-c1451.dist/net/ipv4/igmp.c 2003-10-05 20:42:05.000000000 +0200 +++ linux-2.6.0-test6-c1451/net/ipv4/igmp.c 2003-10-06 15:53:10.000000000 +0200 @@ -1391,8 +1391,9 @@ sf_markstate(pmc); #endif if (!delta) { + err = -EINVAL; if (!pmc->sfcount[sfmode]) - return -EINVAL; + goto out_unlock; pmc->sfcount[sfmode]--; } err = 0; @@ -1423,6 +1424,7 @@ igmp_ifc_event(pmc->interface); #endif } +out_unlock: spin_unlock_bh(&pmc->lock); return err; } From chas@cmf.nrl.navy.mil Mon Oct 6 07:46:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Oct 2003 07:47:05 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h96EkT25010386 for ; Mon, 6 Oct 2003 07:46:30 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id h96EkOkT029882; Mon, 6 Oct 2003 10:46:25 -0400 (EDT) Message-Id: <200310061446.h96EkOkT029882@ginger.cmf.nrl.navy.mil> To: Mitchell Blank Jr cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [RFC] add rtnl semaphore to linux-atm In-Reply-To: Message from Mitchell Blank Jr of "Mon, 06 Oct 2003 02:03:04 PDT." <20031006090304.GD4651@gaz.sfgoth.com> Date: Mon, 06 Oct 2003 10:46:25 -0400 From: chas williams X-Spam-Score: () hits=-0.9 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 564 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev In message <20031006090304.GD4651@gaz.sfgoth.com>,Mitchell Blank Jr writes: >There are no users inside the atm tools that need ATM_ITF_ANY. Anyone >using it directly in a PVC address is already broken and non-determanistic >if they have more than one interface, so I'm not worried if the semantics >in that case are only 90% identical instead of 100% i think the vswitch stuff used it. but it can be made to work w/o too much trouble. >I doubt many crashes happen there (in practice mostly those operations >will be serialized by userland - it's rare to have multiple threads >opening/closing vccs at once) but that doesn't mean that races aren't >hiding. Again, there's zero performance implication to serializing >them so we might as well make the driver API a little more foolproof. so if it isnt a problem why fix it? further, if, as you say, open and close could sleep and possibly for long periods of time then holding this semaphore will block other open/close during this time. that's going to be very annoying. (i have already seen this problem with the old-style SOCKOPS lock_kernel() nonsense. on vcc's that are slow to close the machine basically comes to a complete stop until that vcc is closed). so either you make open/close non sleeping and add a semaphore and just dont add a semaphore. >Yes, but the worst-case is unacceptable. There are at least some people >who have used the code to terminate VCCs coming from DSL customers (a >project like that is actually what got me started with hacking on >linux-atm 5 years ago :-). They could have hundreds of VCCs active at >once. i agree. our atm router typically has something like 100 open at a time. so a linear search here is bad, but the he driver does a little work to make this somewhat more efficient (like caching the mapping since this cant change while under the lock). >Hmmmm... ok. I really believe that we need to sleep in close until the >VCC is truly free. If userland can't do a close followed immediately by >an open on the same vci then something is busted. see above why sleeping is bad. tcp sockets can also get 'stuck' in a close where you cant reopen immediately, TIME_WAIT i believe. From wensong@linux-vs.org Mon Oct 6 10:00:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Oct 2003 10:01:14 -0700 (PDT) Received: from lb1.ctrip.com ([218.244.111.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h96H0I25001546 for ; Mon, 6 Oct 2003 10:00:39 -0700 Received: from penguin.linux-vs.org ([211.136.72.124]) by lb1.ctrip.com (8.12.9/8.12.9) with ESMTP id h96GxY6v014578 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 7 Oct 2003 00:59:55 +0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by penguin.linux-vs.org (8.12.8/8.12.8) with ESMTP id h96GwTul001241; Tue, 7 Oct 2003 00:58:34 +0800 Date: Tue, 7 Oct 2003 00:58:29 +0800 (CST) From: Wensong Zhang To: "David S. Miller" cc: rusty@rustcorp.com.au, Julian Anastasov , , Subject: [2.4 PATCH] two ipvs fixes Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463755008-474097134-1065459509=:1212" X-archive-position: 565 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. ---1463755008-474097134-1065459509=:1212 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Here are IPVS two patches for kernel 2.4, which are basically back ported from the IPVS changes in kernel 2.6. One is to fix ip_vs_tunnel_xmit to return NF_DROP when no memory available, the other is to add strict boundary check in parsing FTP commands. Please check them. Thanks, Wensong ---1463755008-474097134-1065459509=:1212 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="linux-2.4-ipvs-tunnel-xmit.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-2.4-ipvs-tunnel-xmit.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTE0MSAgLT4gMS4xMTQyIA0KIwlu ZXQvaXB2NC9pcHZzL2lwX3ZzX2Nvbm4uYwkxLjEgICAgIC0+IDEuMiAgICAN CiMNCiMgVGhlIGZvbGxvd2luZyBpcyB0aGUgQml0S2VlcGVyIENoYW5nZVNl dCBMb2cNCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCiMgMDMvMTAvMDEJd2Vuc29uZ0BsaW51eC12cy5vcmcJMS4x MTQyDQojIFtJUFZTXSBGaXggaXBfdnNfdHVubmVsX3htaXQgdG8gcmV0dXJu IE5GX0RST1Agd2hlbiBubyBtZW1vcnkgYXZhaWxhYmxlDQojIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQojDQpkaWZm IC1OcnUgYS9uZXQvaXB2NC9pcHZzL2lwX3ZzX2Nvbm4uYyBiL25ldC9pcHY0 L2lwdnMvaXBfdnNfY29ubi5jDQotLS0gYS9uZXQvaXB2NC9pcHZzL2lwX3Zz X2Nvbm4uYwlXZWQgT2N0ICAxIDE5OjU0OjAyIDIwMDMNCisrKyBiL25ldC9p cHY0L2lwdnMvaXBfdnNfY29ubi5jCVdlZCBPY3QgIDEgMTk6NTQ6MDIgMjAw Mw0KQEAgLTkwMyw5ICs5MDMsOCBAQA0KIAkJCXNrYl9yZWFsbG9jX2hlYWRy b29tKHNrYiwgbWF4X2hlYWRyb29tKTsNCiAJCWlmICghbmV3X3NrYikgew0K IAkJCWlwX3J0X3B1dChydCk7DQotCQkJa2ZyZWVfc2tiKHNrYik7DQogCQkJ SVBfVlNfRVJSX1JMKCJpcF92c190dW5