From anand@eis.iisc.ernet.in Thu Jan 1 01:36:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jan 2004 01:36:44 -0800 (PST) Received: from iisc.ernet.in ([144.16.64.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i019aFTa015403 for ; Thu, 1 Jan 2004 01:36:17 -0800 Received: from eis.iisc.ernet.in (eis.iisc.ernet.in [144.16.64.5]) by iisc.ernet.in (8.12.8/8.12.8) with SMTP id i019f9bk016607 for ; Thu, 1 Jan 2004 15:11:09 +0530 Received: by eis.iisc.ernet.in (SMI-8.6/SMI-4.1) id PAA19361; Thu, 1 Jan 2004 15:05:48 +0530 From: anand@eis.iisc.ernet.in (SVR Anand) Message-Id: <200401010935.PAA19361@eis.iisc.ernet.in> Subject: netfilter hook in packet capture To: netdev@oss.sgi.com Date: Thu, 1 Jan 2004 15:05:47 +0530 (GMT+05:30) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2193 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anand@eis.iisc.ernet.in Precedence: bulk X-list: netdev Hi, I am hoping that this mail will be relevant to those who have an user level application that does firewalling by promiscuously capturing packets, apply extensive decision making rules. I have written one such application and found what I am going to say below has helped me a lot. In the above mentioned scenario, there are many instances I preferred to do the following in the kernel itself as much as possible before further processing done in the user firewall code. What I wanted was i) selective packet capture ii) DoS protection iii) Externally controlling the kernel level filter rules without disrupting the firewall application iv) Ease of filter management vi) Logging v) Performance ... I found that iptables/netfilter satisfies all my requirements as compared to the existing bpf filter. Hence all I had to do was include NF_HOOK at couple of places in af_packet.c and I have the netfilter features accessible to me. With the above trivial inclusion I am currently running my application with all the initial work done by netfilter. Thanks netfilter group! While the sanctity or appropriateness or compliance of the above patch within packet capture scheme of things can be frowned upon, since its utility has been beneficial to me, I thought I would share it with you. If you find it useful I can send you rather simple patch which perhaps you could have easily guessed it! Anand From davem@pizda.ninka.net Thu Jan 1 12:29:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jan 2004 12:29:46 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i01KTWTa002355 for ; Thu, 1 Jan 2004 12:29:32 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA10678; Thu, 1 Jan 2004 12:24:31 -0800 Date: Thu, 1 Jan 2004 12:24:30 -0800 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: kill obsolete functions Message-Id: <20040101122430.4fcf6bfd.davem@redhat.com> In-Reply-To: <20040101.154305.69668715.yoshfuji@linux-ipv6.org> References: <20040101.154305.69668715.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2194 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, 01 Jan 2004 15:43:05 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > We've migrated to ip6_append_data(). Old functions such as > ip6_frag_xmit() and ip6_build_xmit() are no longer used. > > D: kill obsolete functions. Applied, arigato Yoshfuji-san. From davem@pizda.ninka.net Thu Jan 1 12:43:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jan 2004 12:43:26 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i01KhBTa002835 for ; Thu, 1 Jan 2004 12:43:13 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA10719; Thu, 1 Jan 2004 12:38:14 -0800 Date: Thu, 1 Jan 2004 12:38:14 -0800 From: "David S. Miller" To: Bart De Schuymer Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] Fix loopback over bridge port Message-Id: <20040101123814.15fdc875.davem@redhat.com> In-Reply-To: <200312271536.46940.bdschuym@pandora.be> References: <200312271536.46940.bdschuym@pandora.be> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2195 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 27 Dec 2003 15:36:46 +0100 Bart De Schuymer wrote: > I think the code (in net/ipv4/ip_output.c::ip_dev_loopback_xmit()) > __skb_pull(newskb, newskb->nh.raw - newskb->data); > is useless, as data always points to the network header at that moment. But > that's not really my territory... I think you're right about this, but the code there doesn't cause any problems either, effectively it's a NOP. One could test out whether you and I are right or not by replacing the __skb_pull() call with BUG_TRAP(skb->nh.raw == skb->data) From davem@pizda.ninka.net Thu Jan 1 12:47:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jan 2004 12:47:26 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i01KlDTa003236 for ; Thu, 1 Jan 2004 12:47:13 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA10731; Thu, 1 Jan 2004 12:42:18 -0800 Date: Thu, 1 Jan 2004 12:42:18 -0800 From: "David S. Miller" To: Jeff Garzik Cc: benh@kernel.crashing.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Problem with dev_kfree_skb_any() in 2.6.0 Message-Id: <20040101124218.258e8b73.davem@redhat.com> In-Reply-To: <3FF1B939.1090108@pobox.com> References: <1072567054.4112.14.camel@gaston> <20031227170755.4990419b.davem@redhat.com> <3FF0FA6A.8000904@pobox.com> <20031229205157.4c631f28.davem@redhat.com> <20031230051519.GA6916@gtf.org> <20031229220122.30078657.davem@redhat.com> <3FF11745.4060705@pobox.com> <20031229221345.31c8c763.davem@redhat.com> <3FF1B939.1090108@pobox.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2196 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 Dec 2003 12:43:21 -0500 Jeff Garzik wrote: > Luckily, I feel there is an easy solution, as shown in the attached > patch. We _already_ queue skbs in dev_kfree_skb_irq(). Therefore, > dev_kfree_skb_any() can simply use precisely that same solution. The > raise-softirq code will immediately proceed to action if we are not in > hard IRQ context, otherwise it will follow the expected path. Ok, this is reasonable and works. Though, is there any particular reason you don't like adding a "|| irqs_disabled()" check to the if statement instead? I prefer that solution better actually. From garzik@gtf.org Thu Jan 1 18:58:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jan 2004 18:58:28 -0800 (PST) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i022wETa017655 for ; Thu, 1 Jan 2004 18:58:15 -0800 Received: by havoc.gtf.org (Postfix, from userid 500) id 26E0E6611; Thu, 1 Jan 2004 21:58:07 -0500 (EST) Date: Thu, 1 Jan 2004 21:58:07 -0500 From: Jeff Garzik To: "David S. Miller" Cc: benh@kernel.crashing.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Problem with dev_kfree_skb_any() in 2.6.0 Message-ID: <20040102025807.GB3851@gtf.org> References: <1072567054.4112.14.camel@gaston> <20031227170755.4990419b.davem@redhat.com> <3FF0FA6A.8000904@pobox.com> <20031229205157.4c631f28.davem@redhat.com> <20031230051519.GA6916@gtf.org> <20031229220122.30078657.davem@redhat.com> <3FF11745.4060705@pobox.com> <20031229221345.31c8c763.davem@redhat.com> <3FF1B939.1090108@pobox.com> <20040101124218.258e8b73.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040101124218.258e8b73.davem@redhat.com> User-Agent: Mutt/1.3.28i X-archive-position: 2197 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 On Thu, Jan 01, 2004 at 12:42:18PM -0800, David S. Miller wrote: > On Tue, 30 Dec 2003 12:43:21 -0500 > Jeff Garzik wrote: > > > Luckily, I feel there is an easy solution, as shown in the attached > > patch. We _already_ queue skbs in dev_kfree_skb_irq(). Therefore, > > dev_kfree_skb_any() can simply use precisely that same solution. The > > raise-softirq code will immediately proceed to action if we are not in > > hard IRQ context, otherwise it will follow the expected path. > > Ok, this is reasonable and works. > > Though, is there any particular reason you don't like adding a > "|| irqs_disabled()" check to the if statement instead? > I prefer that solution better actually. Yep, in fact when I wrote the above message, I came across a couple when I was pondering... * the destructor runs in a more predictable context. * given the problem that started this thread, the 'if' test is a potentially problematic area. Why not eliminate all possibility that this problem will occur again? The only counter argument to this -- to which I have no data to answer -- is that there may be advantage to calling __kfree_skb immediately instead of deferring it slightly. I didn't think that disadvantage outweighted the above, but who knows... I can possibly be convinced otherwise. (and "otherwise" would be using || irqs_disabled()) For the users who don't know/don't care about their context, it just seemed to me that they were not a hot path like users of dev_kfree_skb() and dev_kfree_skb_irq() [unconditional] are... Jeff From scott.feldman@intel.com Thu Jan 1 23:25:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jan 2004 23:25:18 -0800 (PST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i027P5Ta027452 for ; Thu, 1 Jan 2004 23:25:05 -0800 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: major-outer.mc,v 1.12 2003/12/18 18:58:11 root Exp $) with ESMTP id i027PMgd032695; Fri, 2 Jan 2004 07:25:22 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i027PGMQ030344; Fri, 2 Jan 2004 07:25:18 GMT Received: from [134.134.3.50] ([134.134.3.50]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010123240127965 ; Thu, 01 Jan 2004 23:24:01 -0800 Date: Fri, 2 Jan 2004 00:00:41 -0800 (PST) From: "Feldman, Scott" X-X-Sender: scott.feldman@localhost.localdomain Reply-To: "Feldman, Scott" To: Mirko Lindner cc: Jeff Garzik , , , , Subject: Re: [PATCH]sk98lin ethtool support In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id i027P5Ta027452 X-archive-position: 2198 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 On Tue, 30 Dec 2003, Mirko Lindner wrote: > > Make sure you don't duplicate any ethtool functions.  We don't need a > > NIC-specific diag tool either ;-)  ethtool is the preferred method > > moving forward, as it's already shipping in most Linux distros. > > Yes, we need it ;) No kidding! This is not a tool for SW checks like > media, link or driver version checks, but a tool for HW checks like > register, PROM, MAC, PHY and some other chip and card checks. The > ethtool is a great tool, but the intention of this tool is not the same. If the tool reports the results of running the h/w checks, then you can use ETHTOOL_TEST. The summary results of all the tests is reported as PASS/FAIL. Not sure if your tool needs to do more... -scott From uucp@coruscant.gnumonks.org Fri Jan 2 04:12:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jan 2004 04:12:50 -0800 (PST) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i02CCTTa003090 for ; Fri, 2 Jan 2004 04:12:30 -0800 Received: from uucp by coruscant.gnumonks.org with local-bsmtp (Exim 4.20) id 1AcOAF-0003i6-KJ for netdev@oss.sgi.com; Fri, 02 Jan 2004 13:12:27 +0100 Received: from laforge by obroa-skai.gnumonks.org with local (Exim 3.36 #1) id 1AcOA7-0001Xr-00; Fri, 02 Jan 2004 13:12:19 +0100 Date: Fri, 2 Jan 2004 13:12:18 +0100 From: Harald Welte To: SVR Anand Cc: netdev@oss.sgi.com Subject: Re: netfilter hook in packet capture Message-ID: <20040102121218.GK3530@obroa-skai.de.gnumonks.org> References: <200401010935.PAA19361@eis.iisc.ernet.in> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KrHCbChajFcK0yQE" Content-Disposition: inline In-Reply-To: <200401010935.PAA19361@eis.iisc.ernet.in> X-Operating-System: Linux obroa-skai.de.gnumonks.org 2.6.0-test11 X-Date: Today is Prickle-Prickle, the 72nd day of The Aftermath in the YOLD 3169 User-Agent: Mutt/1.5.4i X-archive-position: 2199 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 --KrHCbChajFcK0yQE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 01, 2004 at 03:05:47PM +0530, SVR Anand wrote: > While the sanctity or appropriateness or compliance of the above patch wi= thin > packet capture scheme of things can be frowned upon, since its utility ha= s=20 > been beneficial to me, I thought I would share it with you. If you find it > useful I can send you rather simple patch which perhaps you could have ea= sily > guessed it! We would definitely be interested in such a patch. Please first submit it to the netfilter development team, and we will then push it for kernel inclusion (after any changes/suggestions that we might have). Please send the patch to netfilter-devel@lists.netfilter.org Thanks a lot! > Anand --=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 --KrHCbChajFcK0yQE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/9WAiXaXGVTD0i/8RAjuRAJ4ro+9ux1s7gHn0RPyGD/xgoNCFfACeOys6 A3nHSwc7BsqgWdF5Y1ttJb4= =Cv1I -----END PGP SIGNATURE----- --KrHCbChajFcK0yQE-- From demon@pro-linux.de Fri Jan 2 05:26:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jan 2004 05:27:05 -0800 (PST) Received: from pro-linux.de (4demon.com [217.160.186.4]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i02DQoTa006995 for ; Fri, 2 Jan 2004 05:26:51 -0800 Received: from pro-linux.de (p508B2522.dip.t-dialin.net [80.139.37.34]) by pro-linux.de (Postfix) with ESMTP id B05FE14009E; Fri, 2 Jan 2004 14:26:48 +0100 (CET) Message-ID: <3FF57ECE.5020107@pro-linux.de> Date: Fri, 02 Jan 2004 14:23:10 +0000 From: Mirko Lindner User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Feldman, Scott" Cc: Jeff Garzik , krishnakumar@naturesoft.net, mlindner@syskonnect.de, netdev@oss.sgi.com, felix@allot.com Subject: Re: [PATCH]sk98lin ethtool support References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2200 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: demon@pro-linux.de Precedence: bulk X-list: netdev Feldman, Scott wrote: > On Tue, 30 Dec 2003, Mirko Lindner wrote: > > >>>Make sure you don't duplicate any ethtool functions. We don't need a >>>NIC-specific diag tool either ;-) ethtool is the preferred method >>>moving forward, as it's already shipping in most Linux distros. >> >>Yes, we need it ;) No kidding! This is not a tool for SW checks like >>media, link or driver version checks, but a tool for HW checks like >>register, PROM, MAC, PHY and some other chip and card checks. The >>ethtool is a great tool, but the intention of this tool is not the same. > > > If the tool reports the results of running the h/w checks, then you can > use ETHTOOL_TEST. The summary results of all the tests is reported as > PASS/FAIL. Not sure if your tool needs to do more... > > -scott > > > > > > Scott, thanks for this info, but the tool reports not only the status, but also the results of a test (Example: "Register 0xxxx=xxx", PROM info...). "Problem" 2: All tests are included in the DIAG tool and not in the driver. We have approx. 100 separate tests (over 1000 individual tests) and the driver is huge enough (Support for Genesis, Yukon, Yukon-Lite, Yukon-Plus and Yukon2 chipsets). Mirko From skraw@ithnet.com Fri Jan 2 07:00:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jan 2004 07:00:34 -0800 (PST) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i02F0KTa014253 for ; Fri, 2 Jan 2004 07:00:21 -0800 Received: (qmail 6723 invoked by uid 0); 2 Jan 2004 12:39:14 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.556945 secs); 02 Jan 2004 12:39:14 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 2 Jan 2004 12:39:13 -0000 X-Sender-Authentication: net64 Date: Fri, 2 Jan 2004 13:39:13 +0100 From: Stephan von Krawczynski To: netdev@oss.sgi.com Subject: Re: 2.4 and ip fragmentation question (background info) Message-Id: <20040102133913.488cd537.skraw@ithnet.com> In-Reply-To: <20031231122325.77f19143.skraw@ithnet.com> References: <20031231122325.77f19143.skraw@ithnet.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.8 (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: 2201 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev On Wed, 31 Dec 2003 12:23:25 +0100 Stephan von Krawczynski wrote: > Hello, > > is ip fragmentation thought to work with multiple fragmented packets all with > same ID field, same source and destination address? Or can one consider this > situation as generally unsolvable and broken by application? > > Regards, > Stephan As this question obviously sounded significantly stupid enough not to be answered I may point you to this code in 2.4 include/net/ip.h: static inline void ip_select_ident(struct iphdr *iph, struct dst_entry *dst, struct sock *sk) { if (iph->frag_off&__constant_htons(IP_DF)) { /* This is only to work around buggy Windows95/2000 * VJ compression implementations. If the ID field * does not change, they drop every other packet in * a TCP stream using header compression. */ iph->id = ((sk && sk->daddr) ? htons(sk->protinfo.af_inet.id++) : 0); } else __ip_select_ident(iph, dst); } As you all know this sets the ID field inside the ip-header. Interestingly it depends on frag_off and sk->daddr field. I ran into an application (formerly for 2.2 kernel) where the author (!=me) obviously was unaware of this dependency and initialised these fields after calling ip_select_ident. The outcome was that everything runs normal during low traffic, but when more packets were transferred it looked like a increasing amount of packets got "0" as ID, because iph->frag_off was not initialised correctly and the skbs were of course not zeroed. Still this would have been no problem if these packets weren't fragmented. What I saw was that packets got corrupted during high load (because fragmentation obviously vomitted on the high rate of "ID=0" packets), but all was perfectly well during low load. Should the author have read some doc where it is clearly stated that ip_select_ident needs a more or less completely initialised ip header to work as expected? (other way round see my original question...) Regards, Stephan From Sidharth.Deshpande@fh-heidelberg.de Sat Jan 3 06:40:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jan 2004 06:40:55 -0800 (PST) Received: from proxy.fh-heidelberg.de (dnsfh.fh-heidelberg.de [193.197.74.49]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i03EefTa010720 for ; Sat, 3 Jan 2004 06:40:42 -0800 Received: from EXFBI01.dcs.fh-heidelberg.de (localhost [127.0.0.1]) by proxy.fh-heidelberg.de (Postfix) with ESMTP id 8C9B31EE5B for ; Sat, 3 Jan 2004 15:40:34 +0100 (CET) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: netstat -s X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Sat, 3 Jan 2004 15:40:34 +0100 Message-ID: <842F6B6B3410144AB9937CFECFE446DE804AF5@EXFBI01.dcs.fh-heidelberg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: netstat -s Thread-Index: AcPSB6Kw03MxMWcRQMKrf9who8sE8g== From: "Deshpande, Sidharth (FH)" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i03EefTa010720 X-archive-position: 2202 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Sidharth.Deshpande@fh-heidelberg.de Precedence: bulk X-list: netdev Hello Team, I am looking for explanation of output generated by 'netstat -s' on a Linux box. Would any of you spare some time and please let me know what it means or atleast direct me to a definitive source. Thank you Sidharth Deshpande From krishnakumar@naturesoft.net Sun Jan 4 01:58:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jan 2004 01:58:33 -0800 (PST) Received: from naturesoft.net ([203.145.184.221]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i049wITa029412 for ; Sun, 4 Jan 2004 01:58:19 -0800 Received: from gw3.laser5.co.jp ([211.5.140.198] helo=l5ac210.l5.laser5.co.jp) by naturesoft.net with asmtp (Exim 3.35 #1) id 1Ad4yy-0007Uj-00; Sun, 04 Jan 2004 15:25:41 +0530 Subject: [PATCH] r8169 ethtool support. From: "Krishnakumar. R" Reply-To: krishnakumar@naturesoft.net To: jgarzik@pobox.com Cc: Francois Romieu , netdev@oss.sgi.com Content-Type: text/plain Organization: Naturesoft Ltd Message-Id: <1073210391.3555.7.camel@l5ac210.l5.laser5.co.jp> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 04 Jan 2004 18:59:51 +0900 Content-Transfer-Encoding: 7bit X-archive-position: 2203 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krishnakumar@naturesoft.net Precedence: bulk X-list: netdev Hi, The following patch introduces ethtool support for the r8169 driver. Only the driver info operation will be supported. I dont have the hardware with me, hence has done only a compilation test. The patch is against the latest 2.6.x experimental net driver queue, which is based on 2.6.0-bk2. If found okay, please do apply. Regards, KK. Diffstat output: ---------------- r8169.c | 15 +++++++++++++++ 1 files changed, 15 insertions(+) The patch --------- --- linux-2.6.0-bk2.netdrv.exp/drivers/net/r8169.orig.c 2004-01-04 18:47:10.000000000 +0900 +++ linux-2.6.0-bk2.netdrv.exp/drivers/net/r8169.c 2004-01-04 18:43:06.000000000 +0900 @@ -40,6 +40,7 @@ #include #include #include +#include #include #include @@ -382,6 +383,19 @@ return value; } +static void rtl8169_get_drvinfo (struct net_device *dev, struct ethtool_drvinfo *info) +{ + struct rtl8169_private *tp = dev->priv; + + strcpy (info->driver, RTL8169_DRIVER_NAME); + strcpy (info->version, RTL8169_VERSION ); + strcpy (info->bus_info, pci_name(tp->pci_dev)); +} + +static struct ethtool_ops rtl8169_ethtool_ops = { + .get_drvinfo = rtl8169_get_drvinfo, +}; + static void rtl8169_write_gmii_reg_bit(void *ioaddr, int reg, int bitnum, int bitval) { @@ -793,6 +807,7 @@ dev->open = rtl8169_open; dev->hard_start_xmit = rtl8169_start_xmit; dev->get_stats = rtl8169_get_stats; + dev->ethtool_ops = &rtl8169_ethtool_ops; dev->stop = rtl8169_close; dev->tx_timeout = rtl8169_tx_timeout; dev->set_multicast_list = rtl8169_set_rx_mode; -- Home Page: http://puggy.symonds.net/~krishnakumar/ From sekiya@wide.ad.jp Sun Jan 4 08:06:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jan 2004 08:06:36 -0800 (PST) Received: from yui.nc.u-tokyo.ac.jp (yui.nc.u-tokyo.ac.jp [130.69.251.116]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i04G6LTa021664 for ; Sun, 4 Jan 2004 08:06:22 -0800 Received: from anzu.nc.u-tokyo.ac.jp (anzu.nc.u-tokyo.ac.jp [130.69.251.114]) (authenticated bits=0) by yui.nc.u-tokyo.ac.jp (8.12.10/8.12.3/Debian-6.4) with ESMTP id i04G6EYl011355 for ; Mon, 5 Jan 2004 01:06:15 +0900 Date: Mon, 05 Jan 2004 01:06:09 +0900 Message-ID: From: Yuji Sekiya To: netdev@oss.sgi.com Subject: USAGI STABLE Release 5 User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (=?ISO-2022-JP?B?GyRCNW0lTkMrGyhC?=) FLIM/1.14.4 (=?ISO-2022-JP?B?GyRCM2A4Nj9ANVxBMBsoQg==?=) APEL/10.3 Emacs/20.7 (i386-vine-linux-gnu) MULE/4.1 (=?ISO-2022-JP?B?GyRCMCobKEI=?=) Organization: USAGI Project MIME-Version: 1.0 (generated by SEMI 1.14.3 - =?ISO-2022-JP?B?IhskQjVtGyhC?= =?ISO-2022-JP?B?GyRCJU5DKxsoQiI=?=) Content-Type: text/plain; charset=US-ASCII X-archive-position: 2204 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sekiya@sfc.wide.ad.jp Precedence: bulk X-list: netdev A Happy New Year ! We are glad to announce the USAGI STABLE RELEASE 5, dated on January 4th, 2004. This is the last major STABLE release based on linux-2.4 kernel from USAGI Project. Our primary target of development is moved to linux-2.6 kernel. Changes from the STABLE RELEASE 4.1 are: * based on linux-2.4.21, * IPsec transport/tunnel mode support, * Mobile IPv6 support, * fixed interaction between IPsec and Mobile IPv6, * Default Router Preference Support, and * Route Information Option Support. However, the IPsec and Mobile IPv6 implementations included in this STABLE release may not developed further. Because the IPsec stack was written for linux-2.4 kernel by USAGI Project and currently we have rewritten NEW IPsec stack for linux-2.6 kernel and the stack is included linux-2.6 mainline kernel. The IPsec stack included linux-2.6 kernel is implemented based on "xfrm" architecture and we will continue developing based on the NEW IPsec stack. The Mobile IPv6 stack is the same situation as the IPsec. The Mobile IPv6 stack included in this release is developed by HUT GO Project and the stack is mainly written for linux-2.4 kernel. Currently USAGI Project and GO Project have started joint project for developing new Mobile IPv6 stack based on linux-2.6 kernel. You can get our complete kit which includes kernel tree, library and applications from . We also provide separate patches against the main-line kernel and the tools . Many of our efforts are already in mainline kernel tree. We will continue making reasonable size patches and trying to merge it into mainline kernel tree. We announce the latest information on our web pages. Please check our web site . We also manage the mailing lists for USAGI users. If you have questions, please join the mailing list. Comments and advises are also welcome on that mailing list. Please visit for further information. Thanks. About USAGI Project The USAGI Project is managed by volunteers and aims to provide better IPv6 environment on Linux freely. We are tightly collaborating with WIDE Project, KAME Project and TAHI Project, and trying to improve Linux kernel, IPv6 related libraries and IPv6 applications. Our snapshots are released every two weeks and stable release is released several times a year. Please check our web site http://www.linux-ipv6.org for the latest information. -- USAGI Project members From brad@mainstreetsoftworks.com Sun Jan 4 09:38:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jan 2004 09:38:34 -0800 (PST) Received: from nameserver1.mcve.com (nameserver1.brainwerkz.net [209.251.159.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i04Hc8Ta026827 for ; Sun, 4 Jan 2004 09:38:09 -0800 Received: from mainstreetsoftworks.com (ip68-105-173-45.ga.at.cox.net [68.105.173.45]) by nameserver1.mcve.com (Postfix) with ESMTP id 00D3C85B43; Sun, 4 Jan 2004 12:03:02 -0500 (EST) Message-ID: <3FF846C3.5070207@mainstreetsoftworks.com> Date: Sun, 04 Jan 2004 12:00:51 -0500 From: Brad House User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031121 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu Cc: netdev@oss.sgi.com, Jeff Garzik , brad_mssw@gentoo.org Subject: r8169 in netdev experimental References: <20031122183001.GA16993@gtf.org> <20031124000939.A456@electric-eye.fr.zoreil.com> <20031126004550.A25408@electric-eye.fr.zoreil.com> <20031127235143.A16767@electric-eye.fr.zoreil.com> <20031130014738.A2589@electric-eye.fr.zoreil.com> In-Reply-To: <20031130014738.A2589@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2205 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brad@mainstreetsoftworks.com Precedence: bulk X-list: netdev Ok, sorry I dropped out of existance for a while. I just tried the 2.6.0-bk2 netdev experimental patches, and the r8169 module locks the system on loading. Funny thing is I had to unplug the power cable from the computer for a few seconds and plug it back in, because an immediate reset wouldn't let to old driver work :/ Let me know where to start debugging this, as I should have some time here. (Been busy getting AMD64 port into 'official' mode for Gentoo, so I haven't had time to look into this too much...) Thanks -Brad Francois Romieu wrote: > Hopefully last round of Brad/Realtek's merging. > > Patches apply in this order: > 1 - r8169-hw_start.patch > 2 - r8169-missing-tx-stats.patch > 3 - r8169-intr_mask.patch > > on top of: > > 2.6.0-test11 > + 2.6.0-test9-bk25-netdrvr-exp1 > + r8169-mac-phy-version > + r8169-init_one > + r8169-timer > > The unconditional calls to rtl8169_{rx/tx}_interrupt in rtl8169_interrupt() > are not integrated. That should not make a huge difference. > > -- > Ueimor > > > ------------------------------------------------------------------------ > > > Merge of changes from Realtek: > - register voodoo in rtl8169_hw_start(). > > > drivers/net/r8169.c | 6 ++++++ > 1 files changed, 6 insertions(+) > > diff -puN drivers/net/r8169.c~r8169-hw_start drivers/net/r8169.c > --- linux-2.6.0-test11/drivers/net/r8169.c~r8169-hw_start 2003-11-29 20:36:12.000000000 +0100 > +++ linux-2.6.0-test11-fr/drivers/net/r8169.c 2003-11-29 20:44:17.000000000 +0100 > @@ -1028,6 +1028,12 @@ rtl8169_hw_start(struct net_device *dev) > RTL_W32(TxConfig, > (TX_DMA_BURST << TxDMAShift) | (InterFrameGap << > TxInterFrameGapShift)); > + RTL_W16(CPlusCmd, RTL_R16(CPlusCmd)); > + > + if (tp->mac_version == RTL_GIGA_MAC_VER_D) { > + dprintk(KERN_INFO PFX "Set MAC Reg C+CR Offset 0xE0: bit-3 and bit-14 MUST be 1\n"); > + RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) | (1 << 14) | (1 << 3)); > + } > > tp->cur_rx = 0; > > > _ > > > ------------------------------------------------------------------------ > > > Driver forgot to update the transmitted bytes counter. > Originally done in rtl8169_start_xmit() by Realtek. > > > drivers/net/r8169.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletion(-) > > diff -puN drivers/net/r8169.c~r8169-missing-tx-stats drivers/net/r8169.c > --- linux-2.6.0-test11/drivers/net/r8169.c~r8169-missing-tx-stats 2003-11-29 22:34:10.000000000 +0100 > +++ linux-2.6.0-test11-fr/drivers/net/r8169.c 2003-11-30 00:26:09.000000000 +0100 > @@ -1303,10 +1303,13 @@ rtl8169_tx_interrupt(struct net_device * > int cur = dirty_tx % NUM_TX_DESC; > struct sk_buff *skb = tp->Tx_skbuff[cur]; > > + /* FIXME: is it really accurate for TxErr ? */ > + tp->stats.tx_bytes += skb->len >= ETH_ZLEN ? > + skb->len : ETH_ZLEN; > + tp->stats.tx_packets++; > rtl8169_unmap_tx_skb(tp->pci_dev, tp->Tx_skbuff + cur, > tp->TxDescArray + cur); > dev_kfree_skb_irq(skb); > - tp->stats.tx_packets++; > dirty_tx++; > tx_left--; > entry++; > > _ > > > ------------------------------------------------------------------------ > > drivers/net/r8169.c | 7 ++----- > 1 files changed, 2 insertions(+), 5 deletions(-) > > diff -puN drivers/net/r8169.c~r8169-intr_mask drivers/net/r8169.c > --- linux-2.6.0-test11/drivers/net/r8169.c~r8169-intr_mask 2003-11-30 01:16:48.000000000 +0100 > +++ linux-2.6.0-test11-fr/drivers/net/r8169.c 2003-11-30 01:18:22.000000000 +0100 > @@ -334,8 +334,7 @@ static void rtl8169_tx_timeout(struct ne > static struct net_device_stats *rtl8169_get_stats(struct net_device *netdev); > > static const u16 rtl8169_intr_mask = > - SYSErr | PCSTimeout | RxUnderrun | RxOverflow | RxFIFOOver | TxErr | TxOK | > - RxErr | RxOK; > + RxUnderrun | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK; > static const unsigned int rtl8169_rx_config = > (RX_FIFO_THRESH << RxCfgFIFOShift) | (RX_DMA_BURST << RxCfgDMAShift); > > @@ -1445,9 +1444,7 @@ rtl8169_interrupt(int irq, void *dev_ins > RTL_W16(IntrStatus, > (status & RxFIFOOver) ? (status | RxOverflow) : status); > > - if ((status & > - (SYSErr | PCSTimeout | RxUnderrun | RxOverflow | RxFIFOOver > - | TxErr | TxOK | RxErr | RxOK)) == 0) > + if (!(status & rtl8169_intr_mask)) > break; > > // Rx interrupt > > _ From romieu@fr.zoreil.com Sun Jan 4 14:40:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jan 2004 14:40:46 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i04MeWTa007487 for ; Sun, 4 Jan 2004 14:40:33 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i04McosW003611; Sun, 4 Jan 2004 23:38:50 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i04McnH2003610; Sun, 4 Jan 2004 23:38:49 +0100 Date: Sun, 4 Jan 2004 23:38:49 +0100 From: Francois Romieu To: Brad House Cc: netdev@oss.sgi.com, Jeff Garzik , brad_mssw@gentoo.org Subject: Re: r8169 in netdev experimental Message-ID: <20040104233849.A3214@electric-eye.fr.zoreil.com> References: <20031122183001.GA16993@gtf.org> <20031124000939.A456@electric-eye.fr.zoreil.com> <20031126004550.A25408@electric-eye.fr.zoreil.com> <20031127235143.A16767@electric-eye.fr.zoreil.com> <20031130014738.A2589@electric-eye.fr.zoreil.com> <3FF846C3.5070207@mainstreetsoftworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3FF846C3.5070207@mainstreetsoftworks.com>; from brad@mainstreetsoftworks.com on Sun, Jan 04, 2004 at 12:00:51PM -0500 X-Organisation: Land of Sunshine Inc. X-archive-position: 2206 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Brad House : [...] > Let me know where to start debugging this, as I should > have some time here. static u32 rtl8169_rx_fill(struct rtl8169_private *tp, struct net_device *dev, u32 start, u32 end) { u32 cur; for (cur = start; end - start > 0; cur++) { ^^^^^ This should read: for (cur = start; end - cur > 0; cur++) { Care to test 2.6.1-rc1-mm1 and simply change the offending line ? -- Ueimor From scott.feldman@intel.com Sun Jan 4 16:07:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jan 2004 16:07:38 -0800 (PST) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0507OTa008998 for ; Sun, 4 Jan 2004 16:07:25 -0800 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.12 2003/12/18 18:58:11 root Exp $) with ESMTP id i0504Pmu031989; Mon, 5 Jan 2004 00:04:25 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0508ScU010246; Mon, 5 Jan 2004 00:08:32 GMT Received: from [134.134.3.50] ([134.134.3.50]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010416071211741 ; Sun, 04 Jan 2004 16:07:12 -0800 Date: Sun, 4 Jan 2004 16:43:48 -0800 (PST) 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-exp] back out CSA interrupt fix 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: 2207 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 * 8086:1019 82547 CSA-based LOMs lock up the system with this code, so let's revert back to what's in 2.6.0 until we can figure out why this is causing problems. --------- --- net-drivers-2.5-exp/drivers/net/e1000/e1000_main.c.orig 2004-01-04 15:58:59.000000000 -0800 +++ net-drivers-2.5-exp/drivers/net/e1000/e1000_main.c 2004-01-04 15:59:32.000000000 -0800 @@ -2097,26 +2097,10 @@ __netif_rx_schedule(netdev); } #else - /* Writing IMC and IMS is needed for 82547. - Due to Hub Link bus being occupied, an interrupt - de-assertion message is not able to be sent. - When an interrupt assertion message is generated later, - two messages are re-ordered and sent out. - That causes APIC to think 82547 is in de-assertion - state, while 82547 is in assertion state, resulting - in dead lock. Writing IMC forces 82547 into - de-assertion state. - */ - if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2) - e1000_irq_disable(adapter); - for(i = 0; i < E1000_MAX_INTR; i++) if(!e1000_clean_rx_irq(adapter) & !e1000_clean_tx_irq(adapter)) break; - - if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2) - e1000_irq_enable(adapter); #endif return IRQ_HANDLED; From torvalds@osdl.org Sun Jan 4 18:30:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jan 2004 18:30:43 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i052UTTa013877 for ; Sun, 4 Jan 2004 18:30:29 -0800 Received: from localhost (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i052ULM15312; Sun, 4 Jan 2004 18:30:21 -0800 Date: Sun, 4 Jan 2004 18:30:21 -0800 (PST) From: Linus Torvalds To: Erik Hensema cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: 2.6.0: something is leaking memory In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2208 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: torvalds@osdl.org Precedence: bulk X-list: netdev On Sun, 4 Jan 2004, Erik Hensema wrote: > Linus Torvalds (torvalds@osdl.org) wrote: > > > > Can you do /proc/slabinfo too? > > Sure, this is of course my currently running system, 4 days, 9:53 > uptime. > > slabinfo - version: 2.0 > # name : tunables : slabdata > tcp6_sock 19729 19732 1024 4 1 : tunables 54 27 0 : slabdata 4933 4933 0 You've got 19 _megabytes_ allocated to "tcp6_sock", and they are all marked as "active". That's almost certainly the leaking bug. Everything else looks reasonably normal. > I do use IPv6. I've got three active tunnels and native IPv6 over > ethernet. Yeah, but there is no way you have 19 MB worth of sockets active for three tunnels. David? Linus From yoshfuji@linux-ipv6.org Sun Jan 4 20:52:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jan 2004 20:52:53 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i054qdTa020159 for ; Sun, 4 Jan 2004 20:52:40 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id ABE3033CA5; Mon, 5 Jan 2004 13:52:52 +0900 (JST) Date: Mon, 05 Jan 2004 13:52:52 +0900 (JST) Message-Id: <20040105.135252.07995935.yoshfuji@linux-ipv6.org> To: erik@hensema.net Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: (usagi-core 16947) Re: 2.6.0: something is leaking memory From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: 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: 2209 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 (at Sun, 4 Jan 2004 21:31:26 +0000 (UTC)), Erik Hensema says: > > Can you do /proc/slabinfo too? > > Sure, this is of course my currently running system, 4 days, 9:53 > uptime. > > slabinfo - version: 2.0 > # name : tunables : slabdata : > tcp6_sock 19729 19732 1024 4 1 : tunables 54 27 0 : slabdata 4933 4933 0 : > > Clearly the memory leak isn't in the page cache, so the most likely source > > is network buffers, and most likely in iptables connection tracking or > > similar. If you actually _use_ IPv6, then that is also more likely to have > > leaks just due to less testing. > > I do use IPv6. I've got three active tunnels and native IPv6 over > ethernet. > > I've always had problems with nscd leaking filedescriptors, all > IPv6 connections to my LDAP server. This started after upgrading > suse 8.0 to 8.2 (I think the problem is in nss_ldap). > I'm restarting nscd using a cronjob every night now. Output of > netstat --inet6 -avpn is below. All sockets in CLOSE_WAIT are > leaked and will go away after a nscd restart. How about /proc/slabinfo just after restarting nss_ldap? > The server isn't very critical, but I do need it. I'm willing to > try some patches (or do an upgrade to -mm), but nothing to wild. > > netstat --inet6 -avpn > > Active Internet connections (servers and established) > Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name > tcp 0 0 :::22 :::* LISTEN 1208/sshd > tcp 0 0 :::119 :::* LISTEN 1364/innd > tcp 0 0 :::25 :::* LISTEN 1433/sendmail: acce > tcp 0 0 :::953 :::* LISTEN 1175/named > tcp 0 0 ::1:6010 :::* LISTEN 19900/sshd > tcp 0 0 ::1:6011 :::* LISTEN 20150/sshd > tcp 1 0 ::1:50565 2001:888:10a1::1:389 CLOSE_WAIT 26536/nscd > tcp 1 0 ::1:50224 2001:888:10a1::1:389 CLOSE_WAIT 26536/nscd > tcp 0 0 2001:888:10a1::1:389 ::1:55936 ESTABLISHED 1145/slapd > tcp 1 0 ::1:50343 2001:888:10a1::1:389 CLOSE_WAIT 26536/nscd > tcp 1 0 ::1:50988 2001:888:10a1::1:389 CLOSE_WAIT 26536/nscd : There're too many sockets in CLOSE_WAIT, but the number is very different from "tcp6_sock." And, what is happened when you use ipv4 in your nscd? -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@pizda.ninka.net Sun Jan 4 20:54:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jan 2004 20:54:16 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i054s2Ta020386 for ; Sun, 4 Jan 2004 20:54:03 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id UAA04880; Sun, 4 Jan 2004 20:48:34 -0800 Date: Sun, 4 Jan 2004 20:48:34 -0800 From: "David S. Miller" To: Linus Torvalds Cc: erik@hensema.net, netdev@oss.sgi.com Subject: Re: 2.6.0: something is leaking memory Message-Id: <20040104204834.40b6ca51.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2210 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, 4 Jan 2004 18:30:21 -0800 (PST) Linus Torvalds wrote: > You've got 19 _megabytes_ allocated to "tcp6_sock", and they are all > marked as "active". That's almost certainly the leaking bug. > > Everything else looks reasonably normal. ... > David? Fixed by changeset 1.1496.16.1 which is in 2.6.1-rc1 From madis@cyber.ee Mon Jan 5 04:59:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 04:59:30 -0800 (PST) Received: from alien (pc24.host2.starman.ee [62.65.194.24]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05CxFTa015577 for ; Mon, 5 Jan 2004 04:59:17 -0800 Received: from mzz (helo=localhost) by alien with local-esmtp (Exim 3.36 #1 (Debian)) id 1AdUJl-0000Go-00; Mon, 05 Jan 2004 14:58:49 +0200 Date: Mon, 5 Jan 2004 14:58:48 +0200 (EET) From: madis X-X-Sender: mzz@alien To: Carl-Daniel Hailfinger cc: Madis Janson , netdev@oss.sgi.com Subject: Re: forcedeth unknown events 0x21 In-Reply-To: <3FE6678B.5070006@gmx.net> Message-ID: References: <3FE6678B.5070006@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2211 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: madis@cyber.ee Precedence: bulk X-list: netdev On Mon, 22 Dec 2003, Carl-Daniel Hailfinger wrote: > Madis Janson wrote: > > When trying forcedeth_2_6_patch_v19.txt, i got the following message > > fastly repeating after ifup eth0: > > > > "eth0: received irq with unknown events 0x21. Please report" > > > > and it didn't work eighter (ifup just stalled). > > > > kernel: > > > > 2.6.0 release + patches: > > http://www.held.org.il/patches/patch-lirc-2.6.0-test9-oh.diff.bz2 > > http://www.hailfinger.org/carldani/linux/patches/forcedeth/forcedeth_2_6_patch_v19.txt > > Please try the attached patch on top of it and report back if it works. > the unknown events message disappeared, but the network did not start to work... ======================================================== + if (events & (NVREG_IRQ_RX_ERR)) { + dprintk(KERN_DEBUG "%s: received irq with events 0x%x. Probably RX fail.\n", + dev->name, events); here were '}' missing. -- mzz From mostrows@watson.ibm.com Mon Jan 5 05:08:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 05:08:13 -0800 (PST) Received: from brick.watson.ibm.com (yktgi01e0-s4.watson.ibm.com [129.34.20.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05D7xTa016274 for ; Mon, 5 Jan 2004 05:08:00 -0800 Received: by brick.watson.ibm.com (Postfix, from userid 9965) id E5641C024; Mon, 5 Jan 2004 08:07:58 -0500 (EST) Subject: Deadlock in sungem/ip_auto_config/linkwatch From: Michal Ostrowski To: netdev@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VstyQxFiTA9BMsLFyv50" Message-Id: <1073307882.2041.98320.camel@brick.watson.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 05 Jan 2004 08:07:58 -0500 X-archive-position: 2212 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mostrows@watson.ibm.com Precedence: bulk X-list: netdev --=-VstyQxFiTA9BMsLFyv50 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I believe I've found a potential deadlock condition. It occurs when we make the following sequence of calls: ip_auto_config ic_open_devs dev_change_flags dev_open gem_open flush_scheduled_work ic_open_devs grabs rtnl_sem with an rtnl_shlock() call. The sungem driver at some point calls gem_init_one, which calls netif_carrier_*, which in turn calls schedule_work (linkwatch_event). linkwatch_event in turn needs rtnl_sem. If we enter the call sequence above and linkwatch_event is still pending, we will deadlock since flush_scheduled_work will wait for completion of linkwatch_event, which is blocked since it cannot get rtnl_sem. In general when can one call flush_scheduled_work? It seems that one can't unless you know your callers aren't holding any locks. --=20 Michal Ostrowski --=-VstyQxFiTA9BMsLFyv50 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/+WDqDMDCqU5zPMARAmTwAJ9ujgnF4BI4AVvkhSQ5YgJXBx+sXACfXT+z rx8XL7PYFznObN8IXIZqAW8= =HBFR -----END PGP SIGNATURE----- --=-VstyQxFiTA9BMsLFyv50-- From amir.noam@intel.com Mon Jan 5 07:25:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 07:25:51 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FPPTa021258 for ; Mon, 5 Jan 2004 07:25:27 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i05FPBiI018818; Mon, 5 Jan 2004 15:25:11 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i05FOkwq008552; Mon, 5 Jan 2004 15:25:11 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010517251024220 ; Mon, 05 Jan 2004 17:25:10 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i05FP8hb001043; Mon, 5 Jan 2004 17:25:09 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 0/3] [bonding 2.4] Using per-bond parameters Date: Mon, 5 Jan 2004 17:25:08 +0200 User-Agent: KMail/1.5.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401051725.08348.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2213 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev The following patch set makes each bonding interface keep its own set of parameters, rather than use global values. This is the first step necessary to allow the configuration of different parameters to different bonding interfaces. The patches are against the netdev-2.4 tree (after Shmulik's 'update comment blocks' patch). -- Amir From amir.noam@intel.com Mon Jan 5 07:26:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 07:27:04 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FQmTa021453 for ; Mon, 5 Jan 2004 07:26:49 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i05FQYiI019025; Mon, 5 Jan 2004 15:26:34 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i05FQYwi008750; Mon, 5 Jan 2004 15:26:34 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010517263324268 ; Mon, 05 Jan 2004 17:26:33 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i05FQXhb001058; Mon, 5 Jan 2004 17:26:33 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 1/3] [bonding 2.4] Save parameters in a per-bond data structure Date: Mon, 5 Jan 2004 17:26:26 +0200 User-Agent: KMail/1.5.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401051726.33613.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2214 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev - Save the bonding parameters in a per-bond data structure. - Move all handling of the insmod parameters to bond_check_params(). - Fix the handling of some warning messages regarding parameter use. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Mon Jan 5 17:05:01 2004 +++ b/drivers/net/bonding/bond_main.c Mon Jan 5 17:05:02 2004 @@ -509,7 +509,6 @@ /* monitor all links that often (in milliseconds). <=0 disables monitoring */ #define BOND_LINK_MON_INTERV 0 #define BOND_LINK_ARP_INTERV 0 -#define MAX_ARP_IP_TARGETS 16 static int max_bonds = BOND_DEFAULT_MAX_BONDS; static int miimon = BOND_LINK_MON_INTERV; @@ -520,7 +519,7 @@ static char *mode = NULL; static char *primary = NULL; static char *lacp_rate = NULL; static int arp_interval = BOND_LINK_ARP_INTERV; -static char *arp_ip_target[MAX_ARP_IP_TARGETS] = { NULL, }; +static char *arp_ip_target[BOND_MAX_ARP_TARGETS] = { NULL, }; MODULE_PARM(max_bonds, "i"); MODULE_PARM_DESC(max_bonds, "Max number of bonded devices"); @@ -540,7 +539,7 @@ MODULE_PARM(lacp_rate, "s"); MODULE_PARM_DESC(lacp_rate, "LACPDU tx rate to request from 802.3ad partner (slow/fast)"); MODULE_PARM(arp_interval, "i"); MODULE_PARM_DESC(arp_interval, "arp interval in milliseconds"); -MODULE_PARM(arp_ip_target, "1-" __MODULE_STRING(MAX_ARP_IP_TARGETS) "s"); +MODULE_PARM(arp_ip_target, "1-" __MODULE_STRING(BOND_MAX_ARP_TARGETS) "s"); MODULE_PARM_DESC(arp_ip_target, "arp targets in n.n.n.n form"); /*----------------------------- Global variables ----------------------------*/ @@ -554,7 +553,7 @@ static LIST_HEAD(bond_dev_list); static struct proc_dir_entry *bond_proc_dir = NULL; #endif -static u32 arp_target[MAX_ARP_IP_TARGETS] = { 0, } ; +static u32 arp_target[BOND_MAX_ARP_TARGETS] = { 0, } ; static int arp_ip_count = 0; static u32 my_ip = 0; static int bond_mode = BOND_MODE_ROUNDROBIN; @@ -590,6 +589,10 @@ static struct bond_parm_tbl bond_mode_tb { NULL, -1}, }; +/*-------------------------- Forward declarations ---------------------------*/ + +static inline void bond_set_mode_ops(struct net_device *bond_dev, int mode); + /*---------------------------- General routines -----------------------------*/ static const char *bond_mode_name(void) @@ -2236,7 +2239,7 @@ static void bond_arp_send_all(struct sla { int i; - for (i = 0; (idev, my_ip, NULL, slave->dev->dev_addr, NULL); @@ -3755,13 +3758,47 @@ static int bond_accept_fastpath(struct n /*------------------------- Device initialization ---------------------------*/ /* + * set bond mode specific net device operations + */ +static inline void bond_set_mode_ops(struct net_device *bond_dev, int mode) +{ + switch (mode) { + case BOND_MODE_ROUNDROBIN: + bond_dev->hard_start_xmit = bond_xmit_roundrobin; + break; + case BOND_MODE_ACTIVEBACKUP: + bond_dev->hard_start_xmit = bond_xmit_activebackup; + break; + case BOND_MODE_XOR: + bond_dev->hard_start_xmit = bond_xmit_xor; + break; + case BOND_MODE_BROADCAST: + bond_dev->hard_start_xmit = bond_xmit_broadcast; + break; + case BOND_MODE_8023AD: + bond_dev->hard_start_xmit = bond_3ad_xmit_xor; + break; + case BOND_MODE_TLB: + case BOND_MODE_ALB: + bond_dev->hard_start_xmit = bond_alb_xmit; + bond_dev->set_mac_address = bond_alb_set_mac_address; + break; + default: + /* Should never happen, mode already checked */ + printk(KERN_ERR DRV_NAME + ": Error: Unknown bonding mode %d\n", + mode); + break; + } +} + +/* * Does not allocate but creates a /proc entry. * Allowed to fail. */ -static int __init bond_init(struct net_device *bond_dev) +static int __init bond_init(struct net_device *bond_dev, struct bond_params *params) { struct bonding *bond = bond_dev->priv; - int count; dprintk("Begin bond_init for %s\n", bond_dev->name); @@ -3769,6 +3806,8 @@ static int __init bond_init(struct net_d rwlock_init(&bond->lock); rwlock_init(&bond->curr_slave_lock); + bond->params = *params; /* copy params struct */ + /* Initialize pointers */ bond->first_slave = NULL; bond->curr_active_slave = NULL; @@ -3785,33 +3824,7 @@ static int __init bond_init(struct net_d bond_dev->change_mtu = bond_change_mtu; bond_dev->set_mac_address = bond_set_mac_address; - switch (bond_mode) { - case BOND_MODE_ROUNDROBIN: - bond_dev->hard_start_xmit = bond_xmit_roundrobin; - break; - case BOND_MODE_ACTIVEBACKUP: - bond_dev->hard_start_xmit = bond_xmit_activebackup; - break; - case BOND_MODE_XOR: - bond_dev->hard_start_xmit = bond_xmit_xor; - break; - case BOND_MODE_BROADCAST: - bond_dev->hard_start_xmit = bond_xmit_broadcast; - break; - case BOND_MODE_8023AD: - bond_dev->hard_start_xmit = bond_3ad_xmit_xor; /* extern */ - break; - case BOND_MODE_TLB: - case BOND_MODE_ALB: - bond_dev->hard_start_xmit = bond_alb_xmit; /* extern */ - bond_dev->set_mac_address = bond_alb_set_mac_address; /* extern */ - break; - default: - printk(KERN_ERR DRV_NAME - ": Error: Unknown bonding mode %d\n", - bond_mode); - return -EINVAL; - } + bond_set_mode_ops(bond_dev, bond->params.mode); #ifdef CONFIG_NET_FASTROUTE bond_dev->accept_fastpath = bond_accept_fastpath; @@ -3821,27 +3834,6 @@ static int __init bond_init(struct net_d bond_dev->tx_queue_len = 0; bond_dev->flags |= IFF_MASTER|IFF_MULTICAST; - printk(KERN_INFO DRV_NAME ": %s registered with", bond_dev->name); - if (miimon) { - printk(" MII link monitoring set to %d ms", miimon); - updelay /= miimon; - downdelay /= miimon; - } else { - printk("out MII link monitoring"); - } - printk(", in %s mode.\n", bond_mode_name()); - - printk(KERN_INFO DRV_NAME ": %s registered with", bond_dev->name); - if (arp_interval > 0) { - printk(" ARP monitoring set to %d ms with %d target(s):", - arp_interval, arp_ip_count); - for (count=0 ; countmode = bond_mode; + params->miimon = miimon; + params->arp_interval = arp_interval; + params->updelay = updelay; + params->downdelay = downdelay; + params->use_carrier = use_carrier; + params->lacp_fast = lacp_fast; + params->primary[0] = 0; + + if (primary) { + strncpy(params->primary, primary, IFNAMSIZ); + params->primary[IFNAMSIZ - 1] = 0; + } + + memcpy(params->arp_targets, arp_target, sizeof(arp_target)); + return 0; } static int __init bonding_init(void) { + struct bond_params params; int i; int res; printk(KERN_INFO "%s", version); - res = bond_check_params(); + res = bond_check_params(¶ms); if (res) { return res; } @@ -4158,7 +4182,7 @@ static int __init bonding_init(void) * /proc files), but before register_netdevice(), because we * need to set function pointers. */ - res = bond_init(bond_dev); + res = bond_init(bond_dev, ¶ms); if (res < 0) { free_netdev(bond_dev); goto out_err; diff -Nuarp a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h --- a/drivers/net/bonding/bonding.h Mon Jan 5 17:05:01 2004 +++ b/drivers/net/bonding/bonding.h Mon Jan 5 17:05:02 2004 @@ -36,11 +36,13 @@ #include "bond_3ad.h" #include "bond_alb.h" -#define DRV_VERSION "2.5.3" +#define DRV_VERSION "2.5.4" #define DRV_RELDATE "December 30, 2003" #define DRV_NAME "bonding" #define DRV_DESCRIPTION "Ethernet Channel Bonding Driver" +#define BOND_MAX_ARP_TARGETS 16 + #ifdef BONDING_DEBUG #define dprintk(fmt, args...) \ printk(KERN_DEBUG \ @@ -133,6 +135,18 @@ bond_for_each_slave_from(bond, pos, cnt, (bond)->first_slave) +struct bond_params { + int mode; + int miimon; + int arp_interval; + int use_carrier; + int updelay; + int downdelay; + int lacp_fast; + char primary[IFNAMSIZ]; + u32 arp_targets[BOND_MAX_ARP_TARGETS]; +}; + struct slave { struct net_device *dev; /* first - usefull for panic debug */ struct slave *next; @@ -181,6 +195,7 @@ struct bonding { u16 flags; struct ad_bond_info ad_info; struct alb_bond_info alb_info; + struct bond_params params; }; /** From amir.noam@intel.com Mon Jan 5 07:28:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 07:28:19 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FS3Ta022198 for ; Mon, 5 Jan 2004 07:28:04 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i05FRniI019159; Mon, 5 Jan 2004 15:27:49 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i05FRFx4008811; Mon, 5 Jan 2004 15:27:48 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010517274724296 ; Mon, 05 Jan 2004 17:27:47 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i05FRlhb001081; Mon, 5 Jan 2004 17:27:48 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 2/3] [bonding 2.4] Use the per-bond value of the bond_mode parameter Date: Mon, 5 Jan 2004 17:27:46 +0200 User-Agent: KMail/1.5.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401051727.47839.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2215 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Change usage of the global 'bond_mode' parameter to the per-bond value. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Mon Jan 5 17:05:04 2004 +++ b/drivers/net/bonding/bond_main.c Mon Jan 5 17:05:06 2004 @@ -595,9 +595,9 @@ static inline void bond_set_mode_ops(str /*---------------------------- General routines -----------------------------*/ -static const char *bond_mode_name(void) +static const char *bond_mode_name(int mode) { - switch (bond_mode) { + switch (mode) { case BOND_MODE_ROUNDROBIN : return "load balancing (round-robin)"; case BOND_MODE_ACTIVEBACKUP : @@ -803,7 +803,7 @@ static struct dev_mc_list *bond_mc_list_ */ static void bond_set_promiscuity(struct bonding *bond, int inc) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { /* write lock already acquired */ if (bond->curr_active_slave) { dev_set_promiscuity(bond->curr_active_slave->dev, inc); @@ -822,7 +822,7 @@ static void bond_set_promiscuity(struct */ static void bond_set_allmulti(struct bonding *bond, int inc) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { /* write lock already acquired */ if (bond->curr_active_slave) { dev_set_allmulti(bond->curr_active_slave->dev, inc); @@ -842,7 +842,7 @@ static void bond_set_allmulti(struct bon */ static void bond_mc_add(struct bonding *bond, void *addr, int alen) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { /* write lock already acquired */ if (bond->curr_active_slave) { dev_mc_add(bond->curr_active_slave->dev, addr, alen, 0); @@ -862,7 +862,7 @@ static void bond_mc_add(struct bonding * */ static void bond_mc_delete(struct bonding *bond, void *addr, int alen) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { /* write lock already acquired */ if (bond->curr_active_slave) { dev_mc_delete(bond->curr_active_slave->dev, addr, alen, 0); @@ -922,13 +922,14 @@ static int bond_mc_list_copy(struct dev_ */ static void bond_mc_list_flush(struct net_device *bond_dev, struct net_device *slave_dev) { + struct bonding *bond = bond_dev->priv; struct dev_mc_list *dmi; for (dmi = bond_dev->mc_list; dmi; dmi = dmi->next) { dev_mc_delete(slave_dev, dmi->dmi_addr, dmi->dmi_addrlen, 0); } - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* del lacpdu mc addr from mc list */ u8 lacpdu_multicast[ETH_ALEN] = MULTICAST_LACPDU_ADDR; @@ -947,7 +948,7 @@ static void bond_mc_swap(struct bonding { struct dev_mc_list *dmi; - if (!USES_PRIMARY(bond_mode)) { + if (!USES_PRIMARY(bond->params.mode)) { /* nothing to do - mc list is already up-to-date on * all slaves */ @@ -1064,7 +1065,7 @@ static void bond_change_active_slave(str if (new_active) { if (new_active->link == BOND_LINK_BACK) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { printk(KERN_INFO DRV_NAME ": %s: making interface %s the new " "active one %d ms earlier.\n", @@ -1076,16 +1077,16 @@ static void bond_change_active_slave(str new_active->link = BOND_LINK_UP; new_active->jiffies = jiffies; - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { bond_3ad_handle_link_change(new_active, BOND_LINK_UP); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { bond_alb_handle_link_change(bond, new_active, BOND_LINK_UP); } } else { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { printk(KERN_INFO DRV_NAME ": %s: making interface %s the new " "active one.\n", @@ -1094,7 +1095,7 @@ static void bond_change_active_slave(str } } - if (bond_mode == BOND_MODE_ACTIVEBACKUP) { + if (bond->params.mode == BOND_MODE_ACTIVEBACKUP) { if (old_active) { bond_set_slave_inactive_flags(old_active); } @@ -1104,12 +1105,12 @@ static void bond_change_active_slave(str } } - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { bond_mc_swap(bond, new_active, old_active); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { bond_alb_handle_active_change(bond, new_active); } else { bond->curr_active_slave = new_active; @@ -1264,13 +1265,13 @@ static int bond_enslave(struct net_devic return -EINVAL; } - if ((bond_mode == BOND_MODE_8023AD) || - (bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_8023AD) || + (bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { printk(KERN_ERR DRV_NAME ": Error: to use %s mode, you must upgrade " "ifenslave.\n", - bond_mode_name()); + bond_mode_name(bond->params.mode)); return -EOPNOTSUPP; } } @@ -1326,8 +1327,8 @@ static int bond_enslave(struct net_devic new_slave->dev = slave_dev; - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { /* bond_alb_init_slave() must be called before all other stages since * it might fail and we do not want to have to undo everything */ @@ -1342,7 +1343,7 @@ static int bond_enslave(struct net_devic * curr_active_slave, and that is taken care of later when calling * bond_change_active() */ - if (!USES_PRIMARY(bond_mode)) { + if (!USES_PRIMARY(bond->params.mode)) { /* set promiscuity level to new slave */ if (bond_dev->flags & IFF_PROMISC) { dev_set_promiscuity(slave_dev, 1); @@ -1359,7 +1360,7 @@ static int bond_enslave(struct net_devic } } - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* add lacpdu mc addr to mc list */ u8 lacpdu_multicast[ETH_ALEN] = MULTICAST_LACPDU_ADDR; @@ -1432,7 +1433,7 @@ static int bond_enslave(struct net_devic "forced to 100Mbps, duplex forced to Full.\n", new_slave->dev->name); - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { printk(KERN_WARNING "Operation of 802.3ad mode requires ETHTOOL " "support in base driver for proper aggregator " @@ -1440,14 +1441,14 @@ static int bond_enslave(struct net_devic } } - if (USES_PRIMARY(bond_mode) && primary) { + if (USES_PRIMARY(bond->params.mode) && primary) { /* if there is a primary slave, remember it */ if (strcmp(primary, new_slave->dev->name) == 0) { bond->primary_slave = new_slave; } } - switch (bond_mode) { + switch (bond->params.mode) { case BOND_MODE_ACTIVEBACKUP: /* if we're in active-backup mode, we need one and only one active * interface. The backup interfaces will have their NOARP flag set @@ -1637,7 +1638,7 @@ static int bond_release(struct net_devic } /* Inform AD package of unbinding of slave. */ - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* must be called before the slave is * detached from the list */ @@ -1666,8 +1667,8 @@ static int bond_release(struct net_devic bond_change_active_slave(bond, NULL); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { /* Must be called only after the slave has been * detached from the list and the curr_active_slave * has been cleared (if our_slave == old_current), @@ -1693,7 +1694,7 @@ static int bond_release(struct net_devic * promisc and mc settings if it was the curr_active_slave, but that was * already taken care of above when we detached the slave */ - if (!USES_PRIMARY(bond_mode)) { + if (!USES_PRIMARY(bond->params.mode)) { /* unset promiscuity level from slave */ if (bond_dev->flags & IFF_PROMISC) { dev_set_promiscuity(slave_dev, -1); @@ -1765,15 +1766,15 @@ static int bond_release_all(struct net_d /* Inform AD package of unbinding of slave * before slave is detached from the list. */ - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { bond_3ad_unbind_slave(slave); } slave_dev = slave->dev; bond_detach_slave(bond, slave); - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { /* must be called only after the slave * has been detached from the list */ @@ -1790,7 +1791,7 @@ static int bond_release_all(struct net_d * promisc and mc settings if it was the curr_active_slave, but that was * already taken care of above when we detached the slave */ - if (!USES_PRIMARY(bond_mode)) { + if (!USES_PRIMARY(bond->params.mode)) { /* unset promiscuity level from slave */ if (bond_dev->flags & IFF_PROMISC) { dev_set_promiscuity(slave_dev, -1); @@ -1864,6 +1865,10 @@ static int bond_ioctl_change_active(stru struct slave *new_active = NULL; int res = 0; + if (!USES_PRIMARY(bond->params.mode)) { + return -EINVAL; + } + /* Verify that master_dev is indeed the master of slave_dev */ if (!(slave_dev->flags & IFF_SLAVE) || (slave_dev->master != bond_dev)) { @@ -1952,7 +1957,7 @@ static int bond_info_query(struct net_de { struct bonding *bond = bond_dev->priv; - info->bond_mode = bond_mode; + info->bond_mode = bond->params.mode; info->miimon = miimon; read_lock_bh(&bond->lock); @@ -2054,7 +2059,7 @@ static void bond_mii_monitor(struct net_ "%d ms.\n", bond_dev->name, IS_UP(slave_dev) - ? ((bond_mode == BOND_MODE_ACTIVEBACKUP) + ? ((bond->params.mode == BOND_MODE_ACTIVEBACKUP) ? ((slave == oldcurrent) ? "active " : "backup ") : "") @@ -2076,8 +2081,8 @@ static void bond_mii_monitor(struct net_ /* in active/backup mode, we must * completely disable this interface */ - if ((bond_mode == BOND_MODE_ACTIVEBACKUP) || - (bond_mode == BOND_MODE_8023AD)) { + if ((bond->params.mode == BOND_MODE_ACTIVEBACKUP) || + (bond->params.mode == BOND_MODE_8023AD)) { bond_set_slave_inactive_flags(slave); } @@ -2089,12 +2094,12 @@ static void bond_mii_monitor(struct net_ slave_dev->name); /* notify ad that the link status has changed */ - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { bond_3ad_handle_link_change(slave, BOND_LINK_DOWN); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { bond_alb_handle_link_change(bond, slave, BOND_LINK_DOWN); } @@ -2157,10 +2162,10 @@ static void bond_mii_monitor(struct net_ slave->link = BOND_LINK_UP; slave->jiffies = jiffies; - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* prevent it from being the active one */ slave->state = BOND_STATE_BACKUP; - } else if (bond_mode != BOND_MODE_ACTIVEBACKUP) { + } else if (bond->params.mode != BOND_MODE_ACTIVEBACKUP) { /* make it immediately active */ slave->state = BOND_STATE_ACTIVE; } else if (slave != bond->primary_slave) { @@ -2175,12 +2180,12 @@ static void bond_mii_monitor(struct net_ slave_dev->name); /* notify ad that the link status has changed */ - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { bond_3ad_handle_link_change(slave, BOND_LINK_UP); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { bond_alb_handle_link_change(bond, slave, BOND_LINK_UP); } @@ -2202,7 +2207,7 @@ static void bond_mii_monitor(struct net_ bond_update_speed_duplex(slave); - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { if (old_speed != slave->speed) { bond_3ad_adapter_speed_changed(slave); } @@ -2665,17 +2670,19 @@ static void bond_info_seq_stop(struct se read_unlock(&dev_base_lock); } -static void bond_info_show_master(struct seq_file *seq, struct bonding *bond) +static void bond_info_show_master(struct seq_file *seq) { + struct bonding *bond = seq->private; struct slave *curr; read_lock(&bond->curr_slave_lock); curr = bond->curr_active_slave; read_unlock(&bond->curr_slave_lock); - seq_printf(seq, "Bonding Mode: %s\n", bond_mode_name()); + seq_printf(seq, "Bonding Mode: %s\n", + bond_mode_name(bond->params.mode)); - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { if (curr) { seq_printf(seq, "Currently Active Slave: %s\n", @@ -2688,7 +2695,7 @@ static void bond_info_show_master(struct seq_printf(seq, "Up Delay (ms): %d\n", updelay * miimon); seq_printf(seq, "Down Delay (ms): %d\n", downdelay * miimon); - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { struct ad_info ad_info; seq_puts(seq, "\n802.3ad info\n"); @@ -2720,6 +2727,8 @@ static void bond_info_show_master(struct static void bond_info_show_slave(struct seq_file *seq, const struct slave *slave) { + struct bonding *bond = seq->private; + seq_printf(seq, "\nSlave Interface: %s\n", slave->dev->name); seq_printf(seq, "MII Status: %s\n", (slave->link == BOND_LINK_UP) ? "up" : "down"); @@ -2737,7 +2746,7 @@ static void bond_info_show_slave(struct slave->perm_hwaddr[5]); } - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { const struct aggregator *agg = SLAVE_AD_INFO(slave).port.aggregator; @@ -2754,7 +2763,7 @@ static int bond_info_seq_show(struct seq { if (v == SEQ_START_TOKEN) { seq_printf(seq, "%s\n", version); - bond_info_show_master(seq, seq->private); + bond_info_show_master(seq); } else { bond_info_show_slave(seq, v); } @@ -3030,14 +3039,14 @@ static int bond_open(struct net_device * bond->kill_timers = 0; - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { struct timer_list *alb_timer = &(BOND_ALB_INFO(bond).alb_timer); /* bond_alb_initialize must be called before the timer * is started. */ - if (bond_alb_initialize(bond, (bond_mode == BOND_MODE_ALB))) { + if (bond_alb_initialize(bond, (bond->params.mode == BOND_MODE_ALB))) { /* something went wrong - fail the open operation */ return -1; } @@ -3061,7 +3070,7 @@ static int bond_open(struct net_device * init_timer(arp_timer); arp_timer->expires = jiffies + 1; arp_timer->data = (unsigned long)bond_dev; - if (bond_mode == BOND_MODE_ACTIVEBACKUP) { + if (bond->params.mode == BOND_MODE_ACTIVEBACKUP) { arp_timer->function = (void *)&bond_activebackup_arp_mon; } else { arp_timer->function = (void *)&bond_loadbalance_arp_mon; @@ -3069,7 +3078,7 @@ static int bond_open(struct net_device * add_timer(arp_timer); } - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { struct timer_list *ad_timer = &(BOND_AD_INFO(bond).ad_timer); init_timer(ad_timer); ad_timer->expires = jiffies + 1; @@ -3092,7 +3101,7 @@ static int bond_close(struct net_device bond_mc_list_destroy(bond); - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* Unregister the receive of LACPDUs */ bond_unregister_lacpdu(bond); } @@ -3114,7 +3123,7 @@ static int bond_close(struct net_device del_timer_sync(&bond->arp_timer); } - switch (bond_mode) { + switch (bond->params.mode) { case BOND_MODE_8023AD: del_timer_sync(&(BOND_AD_INFO(bond).ad_timer)); break; @@ -3129,8 +3138,8 @@ static int bond_close(struct net_device /* Release the bonded slaves */ bond_release_all(bond_dev); - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { /* Must be called only after all * slaves have been released */ @@ -3310,11 +3319,7 @@ static int bond_do_ioctl(struct net_devi break; case BOND_CHANGE_ACTIVE_OLD: case SIOCBONDCHANGEACTIVE: - if (USES_PRIMARY(bond_mode)) { - res = bond_ioctl_change_active(bond_dev, slave_dev); - } else { - res = -EINVAL; - } + res = bond_ioctl_change_active(bond_dev, slave_dev); break; default: res = -EOPNOTSUPP; @@ -3919,7 +3924,7 @@ static int bond_check_params(struct bond if (bond_mode != BOND_MODE_8023AD) { printk(KERN_INFO DRV_NAME ": lacp_rate param is irrelevant in mode %s\n", - bond_mode_name()); + bond_mode_name(bond_mode)); } else { lacp_fast = bond_parse_parm(lacp_rate, bond_lacp_tbl); if (lacp_fast == -1) { @@ -4120,7 +4125,7 @@ static int bond_check_params(struct bond printk(KERN_WARNING DRV_NAME ": Warning: %s primary device specified but has no " "effect in %s mode\n", - primary, bond_mode_name()); + primary, bond_mode_name(bond_mode)); primary = NULL; } From amir.noam@intel.com Mon Jan 5 07:29:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 07:29:14 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FSvTa022693 for ; Mon, 5 Jan 2004 07:28:58 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i05FShiI019235; Mon, 5 Jan 2004 15:28:43 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i05FShwi008925; Mon, 5 Jan 2004 15:28:43 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010517284124329 ; Mon, 05 Jan 2004 17:28:41 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i05FSghb001106; Mon, 5 Jan 2004 17:28:42 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 3/3] [bonding 2.4] Use the per-bond values of all remaining parameters Date: Mon, 5 Jan 2004 17:28:41 +0200 User-Agent: KMail/1.5.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401051728.42301.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2216 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Change usage of the all remaining global parameters to the per-bond values. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Mon Jan 5 17:05:08 2004 +++ b/drivers/net/bonding/bond_main.c Mon Jan 5 17:05:10 2004 @@ -458,6 +458,9 @@ * - Fixed: Releasing the original active slave causes mac address duplication. * - Add support for slaves that use ethtool_ops. * Set version to 2.5.3. + * + * 2004/01/05 - Amir Noam + * - Save bonding parameters per bond instead of using the global values. */ //#define BONDING_DEBUG 1 @@ -699,14 +702,14 @@ verify: * It'd be nice if there was a good way to tell if a driver supports * netif_carrier, but there really isn't. */ -static int bond_check_dev_link(struct net_device *slave_dev, int reporting) +static int bond_check_dev_link(struct bonding *bond, struct net_device *slave_dev, int reporting) { static int (* ioctl)(struct net_device *, struct ifreq *, int); struct ifreq ifr; struct mii_ioctl_data *mii; struct ethtool_value etool; - if (use_carrier) { + if (bond->params.use_carrier) { return netif_carrier_ok(slave_dev) ? BMSR_LSTATUS : 0; } @@ -994,7 +997,7 @@ static struct slave *bond_find_best_slav { struct slave *new_active, *old_active; struct slave *bestslave = NULL; - int mintime; + int mintime = bond->params.updelay; int i; new_active = old_active = bond->curr_active_slave; @@ -1007,15 +1010,13 @@ static struct slave *bond_find_best_slav } } - mintime = updelay; - /* first try the primary link; if arping, a link must tx/rx traffic * before it can be considered the curr_active_slave - also, we would skip * slaves between the curr_active_slave and primary_slave that may be up * and able to arp */ if ((bond->primary_slave) && - (!arp_interval) && + (!bond->params.arp_interval) && (IS_UP(bond->primary_slave->dev))) { new_active = bond->primary_slave; } @@ -1070,7 +1071,7 @@ static void bond_change_active_slave(str ": %s: making interface %s the new " "active one %d ms earlier.\n", bond->dev->name, new_active->dev->name, - (updelay - new_active->delay) * miimon); + (bond->params.updelay - new_active->delay) * bond->params.miimon); } new_active->delay = 0; @@ -1374,10 +1375,10 @@ static int bond_enslave(struct net_devic new_slave->delay = 0; new_slave->link_failure_count = 0; - if (miimon && !use_carrier) { - link_reporting = bond_check_dev_link(slave_dev, 1); + if (bond->params.miimon && !bond->params.use_carrier) { + link_reporting = bond_check_dev_link(bond, slave_dev, 1); - if ((link_reporting == -1) && !arp_interval) { + if ((link_reporting == -1) && !bond->params.arp_interval) { /* * miimon is set but a bonded network driver * does not support ETHTOOL/MII and @@ -1407,13 +1408,13 @@ static int bond_enslave(struct net_devic } /* check for initial state */ - if (!miimon || - (bond_check_dev_link(slave_dev, 0) == BMSR_LSTATUS)) { - if (updelay) { + if (!bond->params.miimon || + (bond_check_dev_link(bond, slave_dev, 0) == BMSR_LSTATUS)) { + if (bond->params.updelay) { dprintk("Initial state of slave_dev is " "BOND_LINK_BACK\n"); new_slave->link = BOND_LINK_BACK; - new_slave->delay = updelay; + new_slave->delay = bond->params.updelay; } else { dprintk("Initial state of slave_dev is " "BOND_LINK_UP\n"); @@ -1441,9 +1442,9 @@ static int bond_enslave(struct net_devic } } - if (USES_PRIMARY(bond->params.mode) && primary) { + if (USES_PRIMARY(bond->params.mode) && bond->params.primary[0]) { /* if there is a primary slave, remember it */ - if (strcmp(primary, new_slave->dev->name) == 0) { + if (strcmp(bond->params.primary, new_slave->dev->name) == 0) { bond->primary_slave = new_slave; } } @@ -1482,7 +1483,7 @@ static int bond_enslave(struct net_devic * can be called only after the mac address of the bond is set */ bond_3ad_initialize(bond, 1000/AD_TIMER_INTERVAL, - lacp_fast); + bond->params.lacp_fast); } else { SLAVE_AD_INFO(new_slave).id = SLAVE_AD_INFO(new_slave->prev).id + 1; @@ -1958,7 +1959,7 @@ static int bond_info_query(struct net_de struct bonding *bond = bond_dev->priv; info->bond_mode = bond->params.mode; - info->miimon = miimon; + info->miimon = bond->params.miimon; read_lock_bh(&bond->lock); info->num_slaves = bond->slave_cnt; @@ -2008,11 +2009,13 @@ static void bond_mii_monitor(struct net_ struct bonding *bond = bond_dev->priv; struct slave *slave, *oldcurrent; int do_failover = 0; - int delta_in_ticks = (miimon * HZ) / 1000; + int delta_in_ticks; int i; read_lock(&bond->lock); + delta_in_ticks = (bond->params.miimon * HZ) / 1000; + if (bond->kill_timers) { goto out; } @@ -2037,7 +2040,7 @@ static void bond_mii_monitor(struct net_ u16 old_speed = slave->speed; u8 old_duplex = slave->duplex; - link_state = bond_check_dev_link(slave_dev, 0); + link_state = bond_check_dev_link(bond, slave_dev, 0); switch (slave->link) { case BOND_LINK_UP: /* the link was up */ @@ -2046,13 +2049,13 @@ static void bond_mii_monitor(struct net_ break; } else { /* link going down */ slave->link = BOND_LINK_FAIL; - slave->delay = downdelay; + slave->delay = bond->params.downdelay; if (slave->link_failure_count < UINT_MAX) { slave->link_failure_count++; } - if (downdelay) { + if (bond->params.downdelay) { printk(KERN_INFO DRV_NAME ": %s: link status down for %s " "interface %s, disabling it in " @@ -2065,7 +2068,7 @@ static void bond_mii_monitor(struct net_ : "") : "idle ", slave_dev->name, - downdelay * miimon); + bond->params.downdelay * bond->params.miimon); } } /* no break ! fall through the BOND_LINK_FAIL test to @@ -2117,7 +2120,7 @@ static void bond_mii_monitor(struct net_ ": %s: link status up again after %d " "ms for interface %s.\n", bond_dev->name, - (downdelay - slave->delay) * miimon, + (bond->params.downdelay - slave->delay) * bond->params.miimon, slave_dev->name); } break; @@ -2127,9 +2130,9 @@ static void bond_mii_monitor(struct net_ break; } else { /* link going up */ slave->link = BOND_LINK_BACK; - slave->delay = updelay; + slave->delay = bond->params.updelay; - if (updelay) { + if (bond->params.updelay) { /* if updelay == 0, no need to advertise about a 0 ms delay */ printk(KERN_INFO DRV_NAME @@ -2138,7 +2141,7 @@ static void bond_mii_monitor(struct net_ "in %d ms.\n", bond_dev->name, slave_dev->name, - updelay * miimon); + bond->params.updelay * bond->params.miimon); } } /* no break ! fall through the BOND_LINK_BACK state in @@ -2153,7 +2156,7 @@ static void bond_mii_monitor(struct net_ ": %s: link status down again after %d " "ms for interface %s.\n", bond_dev->name, - (updelay - slave->delay) * miimon, + (bond->params.updelay - slave->delay) * bond->params.miimon, slave_dev->name); } else { /* link stays up */ @@ -2235,17 +2238,20 @@ static void bond_mii_monitor(struct net_ } re_arm: - mod_timer(&bond->mii_timer, jiffies + delta_in_ticks); + if (bond->params.miimon) { + mod_timer(&bond->mii_timer, jiffies + delta_in_ticks); + } out: read_unlock(&bond->lock); } -static void bond_arp_send_all(struct slave *slave) +static void bond_arp_send_all(struct bonding *bond, struct slave *slave) { int i; + u32 *targets = bond->params.arp_targets; - for (i = 0; (i < BOND_MAX_ARP_TARGETS) && arp_target[i]; i++) { - arp_send(ARPOP_REQUEST, ETH_P_ARP, arp_target[i], slave->dev, + for (i = 0; (i < BOND_MAX_ARP_TARGETS) && targets[i]; i++) { + arp_send(ARPOP_REQUEST, ETH_P_ARP, targets[i], slave->dev, my_ip, NULL, slave->dev->dev_addr, NULL); } @@ -2263,11 +2269,13 @@ static void bond_loadbalance_arp_mon(str struct bonding *bond = bond_dev->priv; struct slave *slave, *oldcurrent; int do_failover = 0; - int delta_in_ticks = (arp_interval * HZ) / 1000; + int delta_in_ticks; int i; read_lock(&bond->lock); + delta_in_ticks = (bond->params.arp_interval * HZ) / 1000; + if (bond->kill_timers) { goto out; } @@ -2352,7 +2360,7 @@ static void bond_loadbalance_arp_mon(str * to be unstable during low/no traffic periods */ if (IS_UP(slave->dev)) { - bond_arp_send_all(slave); + bond_arp_send_all(bond, slave); } } @@ -2372,7 +2380,9 @@ static void bond_loadbalance_arp_mon(str } re_arm: - mod_timer(&bond->arp_timer, jiffies + delta_in_ticks); + if (bond->params.arp_interval) { + mod_timer(&bond->arp_timer, jiffies + delta_in_ticks); + } out: read_unlock(&bond->lock); } @@ -2396,11 +2406,13 @@ static void bond_activebackup_arp_mon(st { struct bonding *bond = bond_dev->priv; struct slave *slave; - int delta_in_ticks = (arp_interval * HZ) / 1000; + int delta_in_ticks; int i; read_lock(&bond->lock); + delta_in_ticks = (bond->params.arp_interval * HZ) / 1000; + if (bond->kill_timers) { goto out; } @@ -2559,7 +2571,7 @@ static void bond_activebackup_arp_mon(st * rx traffic */ if (slave && my_ip) { - bond_arp_send_all(slave); + bond_arp_send_all(bond, slave); } } @@ -2580,7 +2592,7 @@ static void bond_activebackup_arp_mon(st if (IS_UP(slave->dev)) { slave->link = BOND_LINK_BACK; bond_set_slave_active_flags(slave); - bond_arp_send_all(slave); + bond_arp_send_all(bond, slave); slave->jiffies = jiffies; bond->current_arp_slave = slave; break; @@ -2612,7 +2624,9 @@ static void bond_activebackup_arp_mon(st } re_arm: - mod_timer(&bond->arp_timer, jiffies + delta_in_ticks); + if (bond->params.arp_interval) { + mod_timer(&bond->arp_timer, jiffies + delta_in_ticks); + } out: read_unlock(&bond->lock); } @@ -2683,22 +2697,27 @@ static void bond_info_show_master(struct bond_mode_name(bond->params.mode)); if (USES_PRIMARY(bond->params.mode)) { - if (curr) { - seq_printf(seq, - "Currently Active Slave: %s\n", - curr->dev->name); - } + seq_printf(seq, "Primary Slave: %s\n", + (bond->params.primary[0]) ? + bond->params.primary : "None"); + + seq_printf(seq, "Currently Active Slave: %s\n", + (curr) ? curr->dev->name : "None"); } seq_printf(seq, "MII Status: %s\n", (curr) ? "up" : "down"); - seq_printf(seq, "MII Polling Interval (ms): %d\n", miimon); - seq_printf(seq, "Up Delay (ms): %d\n", updelay * miimon); - seq_printf(seq, "Down Delay (ms): %d\n", downdelay * miimon); + seq_printf(seq, "MII Polling Interval (ms): %d\n", bond->params.miimon); + seq_printf(seq, "Up Delay (ms): %d\n", + bond->params.updelay * bond->params.miimon); + seq_printf(seq, "Down Delay (ms): %d\n", + bond->params.downdelay * bond->params.miimon); if (bond->params.mode == BOND_MODE_8023AD) { struct ad_info ad_info; seq_puts(seq, "\n802.3ad info\n"); + seq_printf(seq, "LACP rate: %s\n", + (bond->params.lacp_fast) ? "fast" : "slow"); if (bond_3ad_get_active_agg_info(bond, &ad_info)) { seq_printf(seq, "bond %s has no active aggregator\n", @@ -3058,7 +3077,7 @@ static int bond_open(struct net_device * add_timer(alb_timer); } - if (miimon) { /* link check interval, in milliseconds. */ + if (bond->params.miimon) { /* link check interval, in milliseconds. */ init_timer(mii_timer); mii_timer->expires = jiffies + 1; mii_timer->data = (unsigned long)bond_dev; @@ -3066,7 +3085,7 @@ static int bond_open(struct net_device * add_timer(mii_timer); } - if (arp_interval) { /* arp interval, in milliseconds. */ + if (bond->params.arp_interval) { /* arp interval, in milliseconds. */ init_timer(arp_timer); arp_timer->expires = jiffies + 1; arp_timer->data = (unsigned long)bond_dev; @@ -3115,11 +3134,11 @@ static int bond_close(struct net_device * because a running timer might be trying to hold it too */ - if (miimon) { /* link check interval, in milliseconds. */ + if (bond->params.miimon) { /* link check interval, in milliseconds. */ del_timer_sync(&bond->mii_timer); } - if (arp_interval) { /* arp interval, in milliseconds. */ + if (bond->params.arp_interval) { /* arp interval, in milliseconds. */ del_timer_sync(&bond->arp_timer); } @@ -3602,7 +3621,7 @@ static int bond_xmit_activebackup(struct /* if we are sending arp packets, try to at least identify our own ip address */ - if (arp_interval && !my_ip && + if (bond->params.arp_interval && !my_ip && (skb->protocol == __constant_htons(ETH_P_ARP))) { char *the_ip = (char *)skb->data + sizeof(struct ethhdr) + From amir.noam@intel.com Mon Jan 5 07:30:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 07:30:14 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FTxTa023161 for ; Mon, 5 Jan 2004 07:30:00 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i05FTkiI019313; Mon, 5 Jan 2004 15:29:46 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i05FTbwm008981; Mon, 5 Jan 2004 15:29:46 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010517294524378 ; Mon, 05 Jan 2004 17:29:45 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i05FTjhb001129; Mon, 5 Jan 2004 17:29:45 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 0/3] [bonding 2.6] Using per-bond parameters Date: Mon, 5 Jan 2004 17:29:45 +0200 User-Agent: KMail/1.5.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401051729.45524.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2217 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev The following patch set makes each bonding interface keep its own set of parameters, rather than use global values. This is the first step necessary to allow the configuration of different parameters to different bonding interfaces. The patches are against the net-drivers-2.5-exp tree (after Shmulik's 'update comment blocks' patch). -- Amir From amir.noam@intel.com Mon Jan 5 07:30:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 07:30:25 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FUATa023183 for ; Mon, 5 Jan 2004 07:30:11 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i05FTsiI019317; Mon, 5 Jan 2004 15:29:54 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i05FTrwi008988; Mon, 5 Jan 2004 15:29:53 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010517295224380 ; Mon, 05 Jan 2004 17:29:52 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i05FTqhb001132; Mon, 5 Jan 2004 17:29:52 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 1/3] [bonding 2.6] Save parameters in a per-bond data structure Date: Mon, 5 Jan 2004 17:29:51 +0200 User-Agent: KMail/1.5.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401051729.52769.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2218 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev - Save the bonding parameters in a per-bond data structure. - Move all handling of the insmod parameters to bond_check_params(). - Fix the handling of some warning messages regarding parameter use. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Mon Jan 5 17:17:32 2004 +++ b/drivers/net/bonding/bond_main.c Mon Jan 5 17:17:33 2004 @@ -509,7 +509,6 @@ /* monitor all links that often (in milliseconds). <=0 disables monitoring */ #define BOND_LINK_MON_INTERV 0 #define BOND_LINK_ARP_INTERV 0 -#define MAX_ARP_IP_TARGETS 16 static int max_bonds = BOND_DEFAULT_MAX_BONDS; static int miimon = BOND_LINK_MON_INTERV; @@ -520,7 +519,7 @@ static char *mode = NULL; static char *primary = NULL; static char *lacp_rate = NULL; static int arp_interval = BOND_LINK_ARP_INTERV; -static char *arp_ip_target[MAX_ARP_IP_TARGETS] = { NULL, }; +static char *arp_ip_target[BOND_MAX_ARP_TARGETS] = { NULL, }; MODULE_PARM(max_bonds, "i"); MODULE_PARM_DESC(max_bonds, "Max number of bonded devices"); @@ -540,7 +539,7 @@ MODULE_PARM(lacp_rate, "s"); MODULE_PARM_DESC(lacp_rate, "LACPDU tx rate to request from 802.3ad partner (slow/fast)"); MODULE_PARM(arp_interval, "i"); MODULE_PARM_DESC(arp_interval, "arp interval in milliseconds"); -MODULE_PARM(arp_ip_target, "1-" __MODULE_STRING(MAX_ARP_IP_TARGETS) "s"); +MODULE_PARM(arp_ip_target, "1-" __MODULE_STRING(BOND_MAX_ARP_TARGETS) "s"); MODULE_PARM_DESC(arp_ip_target, "arp targets in n.n.n.n form"); /*----------------------------- Global variables ----------------------------*/ @@ -554,7 +553,7 @@ static LIST_HEAD(bond_dev_list); static struct proc_dir_entry *bond_proc_dir = NULL; #endif -static u32 arp_target[MAX_ARP_IP_TARGETS] = { 0, } ; +static u32 arp_target[BOND_MAX_ARP_TARGETS] = { 0, } ; static int arp_ip_count = 0; static u32 my_ip = 0; static int bond_mode = BOND_MODE_ROUNDROBIN; @@ -590,6 +589,10 @@ static struct bond_parm_tbl bond_mode_tb { NULL, -1}, }; +/*-------------------------- Forward declarations ---------------------------*/ + +static inline void bond_set_mode_ops(struct net_device *bond_dev, int mode); + /*---------------------------- General routines -----------------------------*/ static const char *bond_mode_name(void) @@ -2236,7 +2239,7 @@ static void bond_arp_send_all(struct sla { int i; - for (i = 0; (idev, my_ip, NULL, slave->dev->dev_addr, NULL); @@ -3754,13 +3757,47 @@ static int bond_accept_fastpath(struct n /*------------------------- Device initialization ---------------------------*/ /* + * set bond mode specific net device operations + */ +static inline void bond_set_mode_ops(struct net_device *bond_dev, int mode) +{ + switch (mode) { + case BOND_MODE_ROUNDROBIN: + bond_dev->hard_start_xmit = bond_xmit_roundrobin; + break; + case BOND_MODE_ACTIVEBACKUP: + bond_dev->hard_start_xmit = bond_xmit_activebackup; + break; + case BOND_MODE_XOR: + bond_dev->hard_start_xmit = bond_xmit_xor; + break; + case BOND_MODE_BROADCAST: + bond_dev->hard_start_xmit = bond_xmit_broadcast; + break; + case BOND_MODE_8023AD: + bond_dev->hard_start_xmit = bond_3ad_xmit_xor; + break; + case BOND_MODE_TLB: + case BOND_MODE_ALB: + bond_dev->hard_start_xmit = bond_alb_xmit; + bond_dev->set_mac_address = bond_alb_set_mac_address; + break; + default: + /* Should never happen, mode already checked */ + printk(KERN_ERR DRV_NAME + ": Error: Unknown bonding mode %d\n", + mode); + break; + } +} + +/* * Does not allocate but creates a /proc entry. * Allowed to fail. */ -static int __init bond_init(struct net_device *bond_dev) +static int __init bond_init(struct net_device *bond_dev, struct bond_params *params) { struct bonding *bond = bond_dev->priv; - int count; dprintk("Begin bond_init for %s\n", bond_dev->name); @@ -3768,6 +3805,8 @@ static int __init bond_init(struct net_d rwlock_init(&bond->lock); rwlock_init(&bond->curr_slave_lock); + bond->params = *params; /* copy params struct */ + /* Initialize pointers */ bond->first_slave = NULL; bond->curr_active_slave = NULL; @@ -3784,33 +3823,7 @@ static int __init bond_init(struct net_d bond_dev->change_mtu = bond_change_mtu; bond_dev->set_mac_address = bond_set_mac_address; - switch (bond_mode) { - case BOND_MODE_ROUNDROBIN: - bond_dev->hard_start_xmit = bond_xmit_roundrobin; - break; - case BOND_MODE_ACTIVEBACKUP: - bond_dev->hard_start_xmit = bond_xmit_activebackup; - break; - case BOND_MODE_XOR: - bond_dev->hard_start_xmit = bond_xmit_xor; - break; - case BOND_MODE_BROADCAST: - bond_dev->hard_start_xmit = bond_xmit_broadcast; - break; - case BOND_MODE_8023AD: - bond_dev->hard_start_xmit = bond_3ad_xmit_xor; /* extern */ - break; - case BOND_MODE_TLB: - case BOND_MODE_ALB: - bond_dev->hard_start_xmit = bond_alb_xmit; /* extern */ - bond_dev->set_mac_address = bond_alb_set_mac_address; /* extern */ - break; - default: - printk(KERN_ERR DRV_NAME - ": Error: Unknown bonding mode %d\n", - bond_mode); - return -EINVAL; - } + bond_set_mode_ops(bond_dev, bond->params.mode); bond_dev->destructor = free_netdev; #ifdef CONFIG_NET_FASTROUTE @@ -3821,27 +3834,6 @@ static int __init bond_init(struct net_d bond_dev->tx_queue_len = 0; bond_dev->flags |= IFF_MASTER|IFF_MULTICAST; - printk(KERN_INFO DRV_NAME ": %s registered with", bond_dev->name); - if (miimon) { - printk(" MII link monitoring set to %d ms", miimon); - updelay /= miimon; - downdelay /= miimon; - } else { - printk("out MII link monitoring"); - } - printk(", in %s mode.\n", bond_mode_name()); - - printk(KERN_INFO DRV_NAME ": %s registered with", bond_dev->name); - if (arp_interval > 0) { - printk(" ARP monitoring set to %d ms with %d target(s):", - arp_interval, arp_ip_count); - for (count=0 ; countmode = bond_mode; + params->miimon = miimon; + params->arp_interval = arp_interval; + params->updelay = updelay; + params->downdelay = downdelay; + params->use_carrier = use_carrier; + params->lacp_fast = lacp_fast; + params->primary[0] = 0; + + if (primary) { + strncpy(params->primary, primary, IFNAMSIZ); + params->primary[IFNAMSIZ - 1] = 0; + } + + memcpy(params->arp_targets, arp_target, sizeof(arp_target)); + return 0; } static int __init bonding_init(void) { + struct bond_params params; int i; int res; printk(KERN_INFO "%s", version); - res = bond_check_params(); + res = bond_check_params(¶ms); if (res) { return res; } @@ -4157,7 +4181,7 @@ static int __init bonding_init(void) * /proc files), but before register_netdevice(), because we * need to set function pointers. */ - res = bond_init(bond_dev); + res = bond_init(bond_dev, ¶ms); if (res < 0) { free_netdev(bond_dev); goto out_err; diff -Nuarp a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h --- a/drivers/net/bonding/bonding.h Mon Jan 5 17:17:32 2004 +++ b/drivers/net/bonding/bonding.h Mon Jan 5 17:17:33 2004 @@ -36,11 +36,13 @@ #include "bond_3ad.h" #include "bond_alb.h" -#define DRV_VERSION "2.5.3" +#define DRV_VERSION "2.5.4" #define DRV_RELDATE "December 30, 2003" #define DRV_NAME "bonding" #define DRV_DESCRIPTION "Ethernet Channel Bonding Driver" +#define BOND_MAX_ARP_TARGETS 16 + #ifdef BONDING_DEBUG #define dprintk(fmt, args...) \ printk(KERN_DEBUG \ @@ -133,6 +135,18 @@ bond_for_each_slave_from(bond, pos, cnt, (bond)->first_slave) +struct bond_params { + int mode; + int miimon; + int arp_interval; + int use_carrier; + int updelay; + int downdelay; + int lacp_fast; + char primary[IFNAMSIZ]; + u32 arp_targets[BOND_MAX_ARP_TARGETS]; +}; + struct slave { struct net_device *dev; /* first - usefull for panic debug */ struct slave *next; @@ -181,6 +195,7 @@ struct bonding { u16 flags; struct ad_bond_info ad_info; struct alb_bond_info alb_info; + struct bond_params params; }; /** From amir.noam@intel.com Mon Jan 5 07:30:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 07:30:33 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FUGTa023186 for ; Mon, 5 Jan 2004 07:30:18 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i05FU2iI019364; Mon, 5 Jan 2004 15:30:02 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i05FU1wi009034; Mon, 5 Jan 2004 15:30:02 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010517300024382 ; Mon, 05 Jan 2004 17:30:01 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i05FU1hb001173; Mon, 5 Jan 2004 17:30:01 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 2/3] [bonding 2.6] Use the per-bond value of the bond_mode parameter Date: Mon, 5 Jan 2004 17:30:00 +0200 User-Agent: KMail/1.5.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401051730.01365.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2219 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Change usage of the global 'bond_mode' parameter to the per-bond value. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Mon Jan 5 17:17:35 2004 +++ b/drivers/net/bonding/bond_main.c Mon Jan 5 17:17:37 2004 @@ -595,9 +595,9 @@ static inline void bond_set_mode_ops(str /*---------------------------- General routines -----------------------------*/ -static const char *bond_mode_name(void) +static const char *bond_mode_name(int mode) { - switch (bond_mode) { + switch (mode) { case BOND_MODE_ROUNDROBIN : return "load balancing (round-robin)"; case BOND_MODE_ACTIVEBACKUP : @@ -803,7 +803,7 @@ static struct dev_mc_list *bond_mc_list_ */ static void bond_set_promiscuity(struct bonding *bond, int inc) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { /* write lock already acquired */ if (bond->curr_active_slave) { dev_set_promiscuity(bond->curr_active_slave->dev, inc); @@ -822,7 +822,7 @@ static void bond_set_promiscuity(struct */ static void bond_set_allmulti(struct bonding *bond, int inc) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { /* write lock already acquired */ if (bond->curr_active_slave) { dev_set_allmulti(bond->curr_active_slave->dev, inc); @@ -842,7 +842,7 @@ static void bond_set_allmulti(struct bon */ static void bond_mc_add(struct bonding *bond, void *addr, int alen) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { /* write lock already acquired */ if (bond->curr_active_slave) { dev_mc_add(bond->curr_active_slave->dev, addr, alen, 0); @@ -862,7 +862,7 @@ static void bond_mc_add(struct bonding * */ static void bond_mc_delete(struct bonding *bond, void *addr, int alen) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { /* write lock already acquired */ if (bond->curr_active_slave) { dev_mc_delete(bond->curr_active_slave->dev, addr, alen, 0); @@ -922,13 +922,14 @@ static int bond_mc_list_copy(struct dev_ */ static void bond_mc_list_flush(struct net_device *bond_dev, struct net_device *slave_dev) { + struct bonding *bond = bond_dev->priv; struct dev_mc_list *dmi; for (dmi = bond_dev->mc_list; dmi; dmi = dmi->next) { dev_mc_delete(slave_dev, dmi->dmi_addr, dmi->dmi_addrlen, 0); } - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* del lacpdu mc addr from mc list */ u8 lacpdu_multicast[ETH_ALEN] = MULTICAST_LACPDU_ADDR; @@ -947,7 +948,7 @@ static void bond_mc_swap(struct bonding { struct dev_mc_list *dmi; - if (!USES_PRIMARY(bond_mode)) { + if (!USES_PRIMARY(bond->params.mode)) { /* nothing to do - mc list is already up-to-date on * all slaves */ @@ -1064,7 +1065,7 @@ static void bond_change_active_slave(str if (new_active) { if (new_active->link == BOND_LINK_BACK) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { printk(KERN_INFO DRV_NAME ": %s: making interface %s the new " "active one %d ms earlier.\n", @@ -1076,16 +1077,16 @@ static void bond_change_active_slave(str new_active->link = BOND_LINK_UP; new_active->jiffies = jiffies; - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { bond_3ad_handle_link_change(new_active, BOND_LINK_UP); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { bond_alb_handle_link_change(bond, new_active, BOND_LINK_UP); } } else { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { printk(KERN_INFO DRV_NAME ": %s: making interface %s the new " "active one.\n", @@ -1094,7 +1095,7 @@ static void bond_change_active_slave(str } } - if (bond_mode == BOND_MODE_ACTIVEBACKUP) { + if (bond->params.mode == BOND_MODE_ACTIVEBACKUP) { if (old_active) { bond_set_slave_inactive_flags(old_active); } @@ -1104,12 +1105,12 @@ static void bond_change_active_slave(str } } - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { bond_mc_swap(bond, new_active, old_active); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { bond_alb_handle_active_change(bond, new_active); } else { bond->curr_active_slave = new_active; @@ -1264,13 +1265,13 @@ static int bond_enslave(struct net_devic return -EINVAL; } - if ((bond_mode == BOND_MODE_8023AD) || - (bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_8023AD) || + (bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { printk(KERN_ERR DRV_NAME ": Error: to use %s mode, you must upgrade " "ifenslave.\n", - bond_mode_name()); + bond_mode_name(bond->params.mode)); return -EOPNOTSUPP; } } @@ -1326,8 +1327,8 @@ static int bond_enslave(struct net_devic new_slave->dev = slave_dev; - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { /* bond_alb_init_slave() must be called before all other stages since * it might fail and we do not want to have to undo everything */ @@ -1342,7 +1343,7 @@ static int bond_enslave(struct net_devic * curr_active_slave, and that is taken care of later when calling * bond_change_active() */ - if (!USES_PRIMARY(bond_mode)) { + if (!USES_PRIMARY(bond->params.mode)) { /* set promiscuity level to new slave */ if (bond_dev->flags & IFF_PROMISC) { dev_set_promiscuity(slave_dev, 1); @@ -1359,7 +1360,7 @@ static int bond_enslave(struct net_devic } } - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* add lacpdu mc addr to mc list */ u8 lacpdu_multicast[ETH_ALEN] = MULTICAST_LACPDU_ADDR; @@ -1432,7 +1433,7 @@ static int bond_enslave(struct net_devic "forced to 100Mbps, duplex forced to Full.\n", new_slave->dev->name); - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { printk(KERN_WARNING "Operation of 802.3ad mode requires ETHTOOL " "support in base driver for proper aggregator " @@ -1440,14 +1441,14 @@ static int bond_enslave(struct net_devic } } - if (USES_PRIMARY(bond_mode) && primary) { + if (USES_PRIMARY(bond->params.mode) && primary) { /* if there is a primary slave, remember it */ if (strcmp(primary, new_slave->dev->name) == 0) { bond->primary_slave = new_slave; } } - switch (bond_mode) { + switch (bond->params.mode) { case BOND_MODE_ACTIVEBACKUP: /* if we're in active-backup mode, we need one and only one active * interface. The backup interfaces will have their NOARP flag set @@ -1637,7 +1638,7 @@ static int bond_release(struct net_devic } /* Inform AD package of unbinding of slave. */ - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* must be called before the slave is * detached from the list */ @@ -1666,8 +1667,8 @@ static int bond_release(struct net_devic bond_change_active_slave(bond, NULL); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { /* Must be called only after the slave has been * detached from the list and the curr_active_slave * has been cleared (if our_slave == old_current), @@ -1693,7 +1694,7 @@ static int bond_release(struct net_devic * promisc and mc settings if it was the curr_active_slave, but that was * already taken care of above when we detached the slave */ - if (!USES_PRIMARY(bond_mode)) { + if (!USES_PRIMARY(bond->params.mode)) { /* unset promiscuity level from slave */ if (bond_dev->flags & IFF_PROMISC) { dev_set_promiscuity(slave_dev, -1); @@ -1765,15 +1766,15 @@ static int bond_release_all(struct net_d /* Inform AD package of unbinding of slave * before slave is detached from the list. */ - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { bond_3ad_unbind_slave(slave); } slave_dev = slave->dev; bond_detach_slave(bond, slave); - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { /* must be called only after the slave * has been detached from the list */ @@ -1790,7 +1791,7 @@ static int bond_release_all(struct net_d * promisc and mc settings if it was the curr_active_slave, but that was * already taken care of above when we detached the slave */ - if (!USES_PRIMARY(bond_mode)) { + if (!USES_PRIMARY(bond->params.mode)) { /* unset promiscuity level from slave */ if (bond_dev->flags & IFF_PROMISC) { dev_set_promiscuity(slave_dev, -1); @@ -1864,6 +1865,10 @@ static int bond_ioctl_change_active(stru struct slave *new_active = NULL; int res = 0; + if (!USES_PRIMARY(bond->params.mode)) { + return -EINVAL; + } + /* Verify that master_dev is indeed the master of slave_dev */ if (!(slave_dev->flags & IFF_SLAVE) || (slave_dev->master != bond_dev)) { @@ -1952,7 +1957,7 @@ static int bond_info_query(struct net_de { struct bonding *bond = bond_dev->priv; - info->bond_mode = bond_mode; + info->bond_mode = bond->params.mode; info->miimon = miimon; read_lock_bh(&bond->lock); @@ -2054,7 +2059,7 @@ static void bond_mii_monitor(struct net_ "%d ms.\n", bond_dev->name, IS_UP(slave_dev) - ? ((bond_mode == BOND_MODE_ACTIVEBACKUP) + ? ((bond->params.mode == BOND_MODE_ACTIVEBACKUP) ? ((slave == oldcurrent) ? "active " : "backup ") : "") @@ -2076,8 +2081,8 @@ static void bond_mii_monitor(struct net_ /* in active/backup mode, we must * completely disable this interface */ - if ((bond_mode == BOND_MODE_ACTIVEBACKUP) || - (bond_mode == BOND_MODE_8023AD)) { + if ((bond->params.mode == BOND_MODE_ACTIVEBACKUP) || + (bond->params.mode == BOND_MODE_8023AD)) { bond_set_slave_inactive_flags(slave); } @@ -2089,12 +2094,12 @@ static void bond_mii_monitor(struct net_ slave_dev->name); /* notify ad that the link status has changed */ - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { bond_3ad_handle_link_change(slave, BOND_LINK_DOWN); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { bond_alb_handle_link_change(bond, slave, BOND_LINK_DOWN); } @@ -2157,10 +2162,10 @@ static void bond_mii_monitor(struct net_ slave->link = BOND_LINK_UP; slave->jiffies = jiffies; - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* prevent it from being the active one */ slave->state = BOND_STATE_BACKUP; - } else if (bond_mode != BOND_MODE_ACTIVEBACKUP) { + } else if (bond->params.mode != BOND_MODE_ACTIVEBACKUP) { /* make it immediately active */ slave->state = BOND_STATE_ACTIVE; } else if (slave != bond->primary_slave) { @@ -2175,12 +2180,12 @@ static void bond_mii_monitor(struct net_ slave_dev->name); /* notify ad that the link status has changed */ - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { bond_3ad_handle_link_change(slave, BOND_LINK_UP); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { bond_alb_handle_link_change(bond, slave, BOND_LINK_UP); } @@ -2202,7 +2207,7 @@ static void bond_mii_monitor(struct net_ bond_update_speed_duplex(slave); - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { if (old_speed != slave->speed) { bond_3ad_adapter_speed_changed(slave); } @@ -2665,17 +2670,19 @@ static void bond_info_seq_stop(struct se read_unlock(&dev_base_lock); } -static void bond_info_show_master(struct seq_file *seq, struct bonding *bond) +static void bond_info_show_master(struct seq_file *seq) { + struct bonding *bond = seq->private; struct slave *curr; read_lock(&bond->curr_slave_lock); curr = bond->curr_active_slave; read_unlock(&bond->curr_slave_lock); - seq_printf(seq, "Bonding Mode: %s\n", bond_mode_name()); + seq_printf(seq, "Bonding Mode: %s\n", + bond_mode_name(bond->params.mode)); - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { if (curr) { seq_printf(seq, "Currently Active Slave: %s\n", @@ -2688,7 +2695,7 @@ static void bond_info_show_master(struct seq_printf(seq, "Up Delay (ms): %d\n", updelay * miimon); seq_printf(seq, "Down Delay (ms): %d\n", downdelay * miimon); - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { struct ad_info ad_info; seq_puts(seq, "\n802.3ad info\n"); @@ -2720,6 +2727,8 @@ static void bond_info_show_master(struct static void bond_info_show_slave(struct seq_file *seq, const struct slave *slave) { + struct bonding *bond = seq->private; + seq_printf(seq, "\nSlave Interface: %s\n", slave->dev->name); seq_printf(seq, "MII Status: %s\n", (slave->link == BOND_LINK_UP) ? "up" : "down"); @@ -2737,7 +2746,7 @@ static void bond_info_show_slave(struct slave->perm_hwaddr[5]); } - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { const struct aggregator *agg = SLAVE_AD_INFO(slave).port.aggregator; @@ -2754,7 +2763,7 @@ static int bond_info_seq_show(struct seq { if (v == SEQ_START_TOKEN) { seq_printf(seq, "%s\n", version); - bond_info_show_master(seq, seq->private); + bond_info_show_master(seq); } else { bond_info_show_slave(seq, v); } @@ -3029,14 +3038,14 @@ static int bond_open(struct net_device * bond->kill_timers = 0; - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { struct timer_list *alb_timer = &(BOND_ALB_INFO(bond).alb_timer); /* bond_alb_initialize must be called before the timer * is started. */ - if (bond_alb_initialize(bond, (bond_mode == BOND_MODE_ALB))) { + if (bond_alb_initialize(bond, (bond->params.mode == BOND_MODE_ALB))) { /* something went wrong - fail the open operation */ return -1; } @@ -3060,7 +3069,7 @@ static int bond_open(struct net_device * init_timer(arp_timer); arp_timer->expires = jiffies + 1; arp_timer->data = (unsigned long)bond_dev; - if (bond_mode == BOND_MODE_ACTIVEBACKUP) { + if (bond->params.mode == BOND_MODE_ACTIVEBACKUP) { arp_timer->function = (void *)&bond_activebackup_arp_mon; } else { arp_timer->function = (void *)&bond_loadbalance_arp_mon; @@ -3068,7 +3077,7 @@ static int bond_open(struct net_device * add_timer(arp_timer); } - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { struct timer_list *ad_timer = &(BOND_AD_INFO(bond).ad_timer); init_timer(ad_timer); ad_timer->expires = jiffies + 1; @@ -3091,7 +3100,7 @@ static int bond_close(struct net_device bond_mc_list_destroy(bond); - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* Unregister the receive of LACPDUs */ bond_unregister_lacpdu(bond); } @@ -3113,7 +3122,7 @@ static int bond_close(struct net_device del_timer_sync(&bond->arp_timer); } - switch (bond_mode) { + switch (bond->params.mode) { case BOND_MODE_8023AD: del_timer_sync(&(BOND_AD_INFO(bond).ad_timer)); break; @@ -3128,8 +3137,8 @@ static int bond_close(struct net_device /* Release the bonded slaves */ bond_release_all(bond_dev); - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { /* Must be called only after all * slaves have been released */ @@ -3309,11 +3318,7 @@ static int bond_do_ioctl(struct net_devi break; case BOND_CHANGE_ACTIVE_OLD: case SIOCBONDCHANGEACTIVE: - if (USES_PRIMARY(bond_mode)) { - res = bond_ioctl_change_active(bond_dev, slave_dev); - } else { - res = -EINVAL; - } + res = bond_ioctl_change_active(bond_dev, slave_dev); break; default: res = -EOPNOTSUPP; @@ -3918,7 +3923,7 @@ static int bond_check_params(struct bond if (bond_mode != BOND_MODE_8023AD) { printk(KERN_INFO DRV_NAME ": lacp_rate param is irrelevant in mode %s\n", - bond_mode_name()); + bond_mode_name(bond_mode)); } else { lacp_fast = bond_parse_parm(lacp_rate, bond_lacp_tbl); if (lacp_fast == -1) { @@ -4119,7 +4124,7 @@ static int bond_check_params(struct bond printk(KERN_WARNING DRV_NAME ": Warning: %s primary device specified but has no " "effect in %s mode\n", - primary, bond_mode_name()); + primary, bond_mode_name(bond_mode)); primary = NULL; } From amir.noam@intel.com Mon Jan 5 07:30:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 07:30:42 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FUPTa023251 for ; Mon, 5 Jan 2004 07:30:26 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i05FUBiI019422; Mon, 5 Jan 2004 15:30:11 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i05FUBwi009055; Mon, 5 Jan 2004 15:30:11 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010517301024387 ; Mon, 05 Jan 2004 17:30:10 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i05FUAhb001176; Mon, 5 Jan 2004 17:30:10 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 3/3] [bonding 2.6] Use the per-bond values of all remaining parameters Date: Mon, 5 Jan 2004 17:30:09 +0200 User-Agent: KMail/1.5.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401051730.10816.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2220 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Change usage of the all remaining global parameters to the per-bond values. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Mon Jan 5 17:17:39 2004 +++ b/drivers/net/bonding/bond_main.c Mon Jan 5 17:17:40 2004 @@ -458,6 +458,9 @@ * - Fixed: Releasing the original active slave causes mac address duplication. * - Add support for slaves that use ethtool_ops. * Set version to 2.5.3. + * + * 2004/01/05 - Amir Noam + * - Save bonding parameters per bond instead of using the global values. */ //#define BONDING_DEBUG 1 @@ -699,14 +702,14 @@ verify: * It'd be nice if there was a good way to tell if a driver supports * netif_carrier, but there really isn't. */ -static int bond_check_dev_link(struct net_device *slave_dev, int reporting) +static int bond_check_dev_link(struct bonding *bond, struct net_device *slave_dev, int reporting) { static int (* ioctl)(struct net_device *, struct ifreq *, int); struct ifreq ifr; struct mii_ioctl_data *mii; struct ethtool_value etool; - if (use_carrier) { + if (bond->params.use_carrier) { return netif_carrier_ok(slave_dev) ? BMSR_LSTATUS : 0; } @@ -994,7 +997,7 @@ static struct slave *bond_find_best_slav { struct slave *new_active, *old_active; struct slave *bestslave = NULL; - int mintime; + int mintime = bond->params.updelay; int i; new_active = old_active = bond->curr_active_slave; @@ -1007,15 +1010,13 @@ static struct slave *bond_find_best_slav } } - mintime = updelay; - /* first try the primary link; if arping, a link must tx/rx traffic * before it can be considered the curr_active_slave - also, we would skip * slaves between the curr_active_slave and primary_slave that may be up * and able to arp */ if ((bond->primary_slave) && - (!arp_interval) && + (!bond->params.arp_interval) && (IS_UP(bond->primary_slave->dev))) { new_active = bond->primary_slave; } @@ -1070,7 +1071,7 @@ static void bond_change_active_slave(str ": %s: making interface %s the new " "active one %d ms earlier.\n", bond->dev->name, new_active->dev->name, - (updelay - new_active->delay) * miimon); + (bond->params.updelay - new_active->delay) * bond->params.miimon); } new_active->delay = 0; @@ -1374,10 +1375,10 @@ static int bond_enslave(struct net_devic new_slave->delay = 0; new_slave->link_failure_count = 0; - if (miimon && !use_carrier) { - link_reporting = bond_check_dev_link(slave_dev, 1); + if (bond->params.miimon && !bond->params.use_carrier) { + link_reporting = bond_check_dev_link(bond, slave_dev, 1); - if ((link_reporting == -1) && !arp_interval) { + if ((link_reporting == -1) && !bond->params.arp_interval) { /* * miimon is set but a bonded network driver * does not support ETHTOOL/MII and @@ -1407,13 +1408,13 @@ static int bond_enslave(struct net_devic } /* check for initial state */ - if (!miimon || - (bond_check_dev_link(slave_dev, 0) == BMSR_LSTATUS)) { - if (updelay) { + if (!bond->params.miimon || + (bond_check_dev_link(bond, slave_dev, 0) == BMSR_LSTATUS)) { + if (bond->params.updelay) { dprintk("Initial state of slave_dev is " "BOND_LINK_BACK\n"); new_slave->link = BOND_LINK_BACK; - new_slave->delay = updelay; + new_slave->delay = bond->params.updelay; } else { dprintk("Initial state of slave_dev is " "BOND_LINK_UP\n"); @@ -1441,9 +1442,9 @@ static int bond_enslave(struct net_devic } } - if (USES_PRIMARY(bond->params.mode) && primary) { + if (USES_PRIMARY(bond->params.mode) && bond->params.primary[0]) { /* if there is a primary slave, remember it */ - if (strcmp(primary, new_slave->dev->name) == 0) { + if (strcmp(bond->params.primary, new_slave->dev->name) == 0) { bond->primary_slave = new_slave; } } @@ -1482,7 +1483,7 @@ static int bond_enslave(struct net_devic * can be called only after the mac address of the bond is set */ bond_3ad_initialize(bond, 1000/AD_TIMER_INTERVAL, - lacp_fast); + bond->params.lacp_fast); } else { SLAVE_AD_INFO(new_slave).id = SLAVE_AD_INFO(new_slave->prev).id + 1; @@ -1958,7 +1959,7 @@ static int bond_info_query(struct net_de struct bonding *bond = bond_dev->priv; info->bond_mode = bond->params.mode; - info->miimon = miimon; + info->miimon = bond->params.miimon; read_lock_bh(&bond->lock); info->num_slaves = bond->slave_cnt; @@ -2008,11 +2009,13 @@ static void bond_mii_monitor(struct net_ struct bonding *bond = bond_dev->priv; struct slave *slave, *oldcurrent; int do_failover = 0; - int delta_in_ticks = (miimon * HZ) / 1000; + int delta_in_ticks; int i; read_lock(&bond->lock); + delta_in_ticks = (bond->params.miimon * HZ) / 1000; + if (bond->kill_timers) { goto out; } @@ -2037,7 +2040,7 @@ static void bond_mii_monitor(struct net_ u16 old_speed = slave->speed; u8 old_duplex = slave->duplex; - link_state = bond_check_dev_link(slave_dev, 0); + link_state = bond_check_dev_link(bond, slave_dev, 0); switch (slave->link) { case BOND_LINK_UP: /* the link was up */ @@ -2046,13 +2049,13 @@ static void bond_mii_monitor(struct net_ break; } else { /* link going down */ slave->link = BOND_LINK_FAIL; - slave->delay = downdelay; + slave->delay = bond->params.downdelay; if (slave->link_failure_count < UINT_MAX) { slave->link_failure_count++; } - if (downdelay) { + if (bond->params.downdelay) { printk(KERN_INFO DRV_NAME ": %s: link status down for %s " "interface %s, disabling it in " @@ -2065,7 +2068,7 @@ static void bond_mii_monitor(struct net_ : "") : "idle ", slave_dev->name, - downdelay * miimon); + bond->params.downdelay * bond->params.miimon); } } /* no break ! fall through the BOND_LINK_FAIL test to @@ -2117,7 +2120,7 @@ static void bond_mii_monitor(struct net_ ": %s: link status up again after %d " "ms for interface %s.\n", bond_dev->name, - (downdelay - slave->delay) * miimon, + (bond->params.downdelay - slave->delay) * bond->params.miimon, slave_dev->name); } break; @@ -2127,9 +2130,9 @@ static void bond_mii_monitor(struct net_ break; } else { /* link going up */ slave->link = BOND_LINK_BACK; - slave->delay = updelay; + slave->delay = bond->params.updelay; - if (updelay) { + if (bond->params.updelay) { /* if updelay == 0, no need to advertise about a 0 ms delay */ printk(KERN_INFO DRV_NAME @@ -2138,7 +2141,7 @@ static void bond_mii_monitor(struct net_ "in %d ms.\n", bond_dev->name, slave_dev->name, - updelay * miimon); + bond->params.updelay * bond->params.miimon); } } /* no break ! fall through the BOND_LINK_BACK state in @@ -2153,7 +2156,7 @@ static void bond_mii_monitor(struct net_ ": %s: link status down again after %d " "ms for interface %s.\n", bond_dev->name, - (updelay - slave->delay) * miimon, + (bond->params.updelay - slave->delay) * bond->params.miimon, slave_dev->name); } else { /* link stays up */ @@ -2235,17 +2238,20 @@ static void bond_mii_monitor(struct net_ } re_arm: - mod_timer(&bond->mii_timer, jiffies + delta_in_ticks); + if (bond->params.miimon) { + mod_timer(&bond->mii_timer, jiffies + delta_in_ticks); + } out: read_unlock(&bond->lock); } -static void bond_arp_send_all(struct slave *slave) +static void bond_arp_send_all(struct bonding *bond, struct slave *slave) { int i; + u32 *targets = bond->params.arp_targets; - for (i = 0; (i < BOND_MAX_ARP_TARGETS) && arp_target[i]; i++) { - arp_send(ARPOP_REQUEST, ETH_P_ARP, arp_target[i], slave->dev, + for (i = 0; (i < BOND_MAX_ARP_TARGETS) && targets[i]; i++) { + arp_send(ARPOP_REQUEST, ETH_P_ARP, targets[i], slave->dev, my_ip, NULL, slave->dev->dev_addr, NULL); } @@ -2263,11 +2269,13 @@ static void bond_loadbalance_arp_mon(str struct bonding *bond = bond_dev->priv; struct slave *slave, *oldcurrent; int do_failover = 0; - int delta_in_ticks = (arp_interval * HZ) / 1000; + int delta_in_ticks; int i; read_lock(&bond->lock); + delta_in_ticks = (bond->params.arp_interval * HZ) / 1000; + if (bond->kill_timers) { goto out; } @@ -2352,7 +2360,7 @@ static void bond_loadbalance_arp_mon(str * to be unstable during low/no traffic periods */ if (IS_UP(slave->dev)) { - bond_arp_send_all(slave); + bond_arp_send_all(bond, slave); } } @@ -2372,7 +2380,9 @@ static void bond_loadbalance_arp_mon(str } re_arm: - mod_timer(&bond->arp_timer, jiffies + delta_in_ticks); + if (bond->params.arp_interval) { + mod_timer(&bond->arp_timer, jiffies + delta_in_ticks); + } out: read_unlock(&bond->lock); } @@ -2396,11 +2406,13 @@ static void bond_activebackup_arp_mon(st { struct bonding *bond = bond_dev->priv; struct slave *slave; - int delta_in_ticks = (arp_interval * HZ) / 1000; + int delta_in_ticks; int i; read_lock(&bond->lock); + delta_in_ticks = (bond->params.arp_interval * HZ) / 1000; + if (bond->kill_timers) { goto out; } @@ -2559,7 +2571,7 @@ static void bond_activebackup_arp_mon(st * rx traffic */ if (slave && my_ip) { - bond_arp_send_all(slave); + bond_arp_send_all(bond, slave); } } @@ -2580,7 +2592,7 @@ static void bond_activebackup_arp_mon(st if (IS_UP(slave->dev)) { slave->link = BOND_LINK_BACK; bond_set_slave_active_flags(slave); - bond_arp_send_all(slave); + bond_arp_send_all(bond, slave); slave->jiffies = jiffies; bond->current_arp_slave = slave; break; @@ -2612,7 +2624,9 @@ static void bond_activebackup_arp_mon(st } re_arm: - mod_timer(&bond->arp_timer, jiffies + delta_in_ticks); + if (bond->params.arp_interval) { + mod_timer(&bond->arp_timer, jiffies + delta_in_ticks); + } out: read_unlock(&bond->lock); } @@ -2683,22 +2697,27 @@ static void bond_info_show_master(struct bond_mode_name(bond->params.mode)); if (USES_PRIMARY(bond->params.mode)) { - if (curr) { - seq_printf(seq, - "Currently Active Slave: %s\n", - curr->dev->name); - } + seq_printf(seq, "Primary Slave: %s\n", + (bond->params.primary[0]) ? + bond->params.primary : "None"); + + seq_printf(seq, "Currently Active Slave: %s\n", + (curr) ? curr->dev->name : "None"); } seq_printf(seq, "MII Status: %s\n", (curr) ? "up" : "down"); - seq_printf(seq, "MII Polling Interval (ms): %d\n", miimon); - seq_printf(seq, "Up Delay (ms): %d\n", updelay * miimon); - seq_printf(seq, "Down Delay (ms): %d\n", downdelay * miimon); + seq_printf(seq, "MII Polling Interval (ms): %d\n", bond->params.miimon); + seq_printf(seq, "Up Delay (ms): %d\n", + bond->params.updelay * bond->params.miimon); + seq_printf(seq, "Down Delay (ms): %d\n", + bond->params.downdelay * bond->params.miimon); if (bond->params.mode == BOND_MODE_8023AD) { struct ad_info ad_info; seq_puts(seq, "\n802.3ad info\n"); + seq_printf(seq, "LACP rate: %s\n", + (bond->params.lacp_fast) ? "fast" : "slow"); if (bond_3ad_get_active_agg_info(bond, &ad_info)) { seq_printf(seq, "bond %s has no active aggregator\n", @@ -3057,7 +3076,7 @@ static int bond_open(struct net_device * add_timer(alb_timer); } - if (miimon) { /* link check interval, in milliseconds. */ + if (bond->params.miimon) { /* link check interval, in milliseconds. */ init_timer(mii_timer); mii_timer->expires = jiffies + 1; mii_timer->data = (unsigned long)bond_dev; @@ -3065,7 +3084,7 @@ static int bond_open(struct net_device * add_timer(mii_timer); } - if (arp_interval) { /* arp interval, in milliseconds. */ + if (bond->params.arp_interval) { /* arp interval, in milliseconds. */ init_timer(arp_timer); arp_timer->expires = jiffies + 1; arp_timer->data = (unsigned long)bond_dev; @@ -3114,11 +3133,11 @@ static int bond_close(struct net_device * because a running timer might be trying to hold it too */ - if (miimon) { /* link check interval, in milliseconds. */ + if (bond->params.miimon) { /* link check interval, in milliseconds. */ del_timer_sync(&bond->mii_timer); } - if (arp_interval) { /* arp interval, in milliseconds. */ + if (bond->params.arp_interval) { /* arp interval, in milliseconds. */ del_timer_sync(&bond->arp_timer); } @@ -3601,7 +3620,7 @@ static int bond_xmit_activebackup(struct /* if we are sending arp packets, try to at least identify our own ip address */ - if (arp_interval && !my_ip && + if (bond->params.arp_interval && !my_ip && (skb->protocol == __constant_htons(ETH_P_ARP))) { char *the_ip = (char *)skb->data + sizeof(struct ethhdr) + From srompf@isg.de Mon Jan 5 07:32:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 07:32:20 -0800 (PST) Received: from mail.isg.de (rzfoobar.is-asp.com [217.11.194.155]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FVuTa024600 for ; Mon, 5 Jan 2004 07:31:57 -0800 Received: from barkeeper.frankfurter-softwarefabrik.de (barkeeper.frankfurter-softwarefabrik.de [192.168.6.182]) by mail.isg.de (Postfix) with ESMTP id 27A1EE49224; Mon, 5 Jan 2004 15:50:52 +0100 (CET) From: Stefan Rompf To: Michal Ostrowski , netdev@oss.sgi.com Subject: Re: Deadlock in sungem/ip_auto_config/linkwatch Date: Mon, 5 Jan 2004 15:50:50 +0100 User-Agent: KMail/1.5.94 References: <1073307882.2041.98320.camel@brick.watson.ibm.com> In-Reply-To: <1073307882.2041.98320.camel@brick.watson.ibm.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200401051550.51063.srompf@isg.de> X-archive-position: 2221 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: srompf@isg.de Precedence: bulk X-list: netdev Am Montag, 05. Januar 2004 14:07 schrieb Michal Ostrowski: > ic_open_devs grabs rtnl_sem with an rtnl_shlock() call. > > The sungem driver at some point calls gem_init_one, which calls > netif_carrier_*, which in turn calls schedule_work (linkwatch_event). > > linkwatch_event in turn needs rtnl_sem. Good catch! The sungem driver shows clearly that we need some way to remove queued work without scheduling and waiting for other events. I will change the linkwatch code to use rtnl_shlock_nowait() and backoff and retry in case of failure this week. Call it a workaround, but it increases overall system stability. Btw, what is the planned difference between rtnl_shlock() and rtnl_exlock()? Even though the later is a null operation right now, I don't want to hold more locks than needed in the linkwatch code. Stefan -- "doesn't work" is not a magic word to explain everything. From mostrows@watson.ibm.com Mon Jan 5 08:19:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 08:19:41 -0800 (PST) Received: from brick.watson.ibm.com (yktgi01e0-s4.watson.ibm.com [129.34.20.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05GJQTa031239 for ; Mon, 5 Jan 2004 08:19:27 -0800 Received: by brick.watson.ibm.com (Postfix, from userid 9965) id 91C54BFA3; Mon, 5 Jan 2004 11:19:25 -0500 (EST) Subject: Re: Deadlock in sungem/ip_auto_config/linkwatch From: Michal Ostrowski To: Stefan Rompf Cc: netdev@oss.sgi.com In-Reply-To: <200401051550.51063.srompf@isg.de> References: <1073307882.2041.98320.camel@brick.watson.ibm.com> <200401051550.51063.srompf@isg.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-T7Vi+m2S37xHNyQWLC01" Message-Id: <1073319565.2043.98923.camel@brick.watson.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 05 Jan 2004 11:19:25 -0500 X-archive-position: 2222 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mostrows@watson.ibm.com Precedence: bulk X-list: netdev --=-T7Vi+m2S37xHNyQWLC01 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable This can get pretty hairy. Suppose the linkwatch code backs-off in the case that rtnl_sem is held legitimately by thread A. Meanwhile, thread B is doing a flush_scheduled_work in order to wait for pending linkwatch events to complete. =20 In the proposed solution this will result in incorrect behaviour (flush_scheduled_work returns with the linkwatch work not really done).=20 (Admittedly I'm not sure if such a scenario really is feasible.) My initial though was to use a seperate work-queue, un-entangled with the global queue used for flush_scheduled_work. This would allow linkwatch events to be synchronized against explicitly. For this solution though I think it would be nice to not have to have a thread per cpu for the linkwatch work queue. On the other hand, ic_open_devs appears to be the only place where rtnl_sem is held while going into a driver's open() function, and so maybe the right rule is that rtnl_sem is not held when calling dev->open(). --=20 Michal Ostrowski On Mon, 2004-01-05 at 09:50, Stefan Rompf wrote: > Am Montag, 05. Januar 2004 14:07 schrieb Michal Ostrowski: >=20 > > ic_open_devs grabs rtnl_sem with an rtnl_shlock() call. > > > > The sungem driver at some point calls gem_init_one, which calls > > netif_carrier_*, which in turn calls schedule_work (linkwatch_event). > > > > linkwatch_event in turn needs rtnl_sem. >=20 > Good catch! The sungem driver shows clearly that we need some way to remo= ve=20 > queued work without scheduling and waiting for other events. >=20 > I will change the linkwatch code to use rtnl_shlock_nowait() and backoff = and=20 > retry in case of failure this week. Call it a workaround, but it increase= s=20 > overall system stability. >=20 > Btw, what is the planned difference between rtnl_shlock() and rtnl_exlock= ()?=20 > Even though the later is a null operation right now, I don't want to hold= =20 > more locks than needed in the linkwatch code. >=20 > Stefan >=20 --=-T7Vi+m2S37xHNyQWLC01 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/+Y6MDMDCqU5zPMARAhzgAKCYfZQv5KwkiFbAsdhEoMaLk4ZgkwCdEclN kHFuP/wl7cmOAbijpPORTco= =+eos -----END PGP SIGNATURE----- --=-T7Vi+m2S37xHNyQWLC01-- From srompf@isg.de Mon Jan 5 09:29:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 09:29:21 -0800 (PST) Received: from mail.isg.de (rzfoobar.is-asp.com [217.11.194.155]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05HSvTa003296 for ; Mon, 5 Jan 2004 09:28:58 -0800 Received: from barkeeper.frankfurter-softwarefabrik.de (barkeeper.frankfurter-softwarefabrik.de [192.168.6.182]) by mail.isg.de (Postfix) with ESMTP id 866F8126644C; Mon, 5 Jan 2004 17:50:57 +0100 (CET) From: Stefan Rompf To: Michal Ostrowski Subject: Re: Deadlock in sungem/ip_auto_config/linkwatch Date: Mon, 5 Jan 2004 17:50:55 +0100 User-Agent: KMail/1.5.94 Cc: netdev@oss.sgi.com References: <1073307882.2041.98320.camel@brick.watson.ibm.com> <200401051550.51063.srompf@isg.de> <1073319565.2043.98923.camel@brick.watson.ibm.com> In-Reply-To: <1073319565.2043.98923.camel@brick.watson.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="Boundary-02=_wXZ+/M91EO8KJ7L"; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200401051750.56233.srompf@isg.de> X-archive-position: 2223 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: srompf@isg.de Precedence: bulk X-list: netdev --Boundary-02=_wXZ+/M91EO8KJ7L Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Montag, 05. Januar 2004 17:19 schrieb Michal Ostrowski: > Suppose the linkwatch code backs-off in the case that rtnl_sem is held > legitimately by thread A. Meanwhile, thread B is doing a > flush_scheduled_work in order to wait for pending linkwatch events to > complete. This won't happen. If a pending linkwatch event needs to be scheduled=20 synchronously (f.e. when a device is unregistered), it is executed in conte= xt=20 of the calling process, not inside the workqueue thread. > My initial though was to use a seperate work-queue, un-entangled with > the global queue used for flush_scheduled_work. This would allow > linkwatch events to be synchronized against explicitly. That's overkill, and if I understand flush_workqueue() right, it doesn't ca= re=20 about work that is queued with delay, so it even wouldn't help. That's why = I=20 thought about a function to unregister pending work. Stefan =2D-=20 "doesn't work" is not a magic word to explain everything. --Boundary-02=_wXZ+/M91EO8KJ7L Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Description: signature Content-Disposition: attachment; filename="smime.p7s" MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBEAw ggQ8MIIDpaADAgECAgFHMA0GCSqGSIb3DQEBBAUAMIG+MQswCQYDVQQGEwJERTEPMA0GA1UECBMG SGVzc2VuMRowGAYDVQQHExFGcmFua2Z1cnQgYW0gTWFpbjEhMB8GA1UEChMYSW5ub3ZhdGl2ZSBT b2Z0d2FyZSBHbWJIMR8wHQYDVQQLExZOZXR3b3JrIEFkbWluaXN0cmF0aW9uMSIwIAYDVQQDExlJ U0cgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRowGAYJKoZIhvcNAQkBFgtpbmZvQGlzZy5kZTAeFw0w MDA2MDUxMjIyNDlaFw0xMDAzMDUxMjIyNDlaMIG6MQswCQYDVQQGEwJERTEPMA0GA1UECBMGSGVz c2VuMRowGAYDVQQHExFGcmFua2Z1cnQgYW0gTWFpbjEhMB8GA1UEChMYSW5ub3ZhdGl2ZSBTb2Z0 d2FyZSBHbWJIMR0wGwYDVQQLExRTb2Z0d2FyZSBEZXZlbG9wbWVudDEeMBwGA1UEAxMVU3RlZmFu IFJvbXBmIChJU0cgQ0EpMRwwGgYJKoZIhvcNAQkBFg1zcm9tcGZAaXNnLmRlMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDBTlj0vQ81p59aQUY3XX81RM0MrcLzq5l5VetfLQOS4aTmwk/32siO rXQxxTwODgmui/kLzSgRRYqFtDfelSWvsrtYR4VaH3I1u7YgcXWTx4oTt0RdiMvJ3/VgKmfpbpRN DlyuV7b8daC+0vpMKbhBJyt5716u9LHrMZZbw5n1gwIDAQABo4IBSjCCAUYwCQYDVR0TBAIwADAs BglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHGF b48a5LAWDpGcbEPw8Vn2aUYyMIHrBgNVHSMEgeMwgeCAFJyzCKYgVHSxntGNkKK4rHhml9G6oYHE pIHBMIG+MQswCQYDVQQGEwJERTEPMA0GA1UECBMGSGVzc2VuMRowGAYDVQQHExFGcmFua2Z1cnQg YW0gTWFpbjEhMB8GA1UEChMYSW5ub3ZhdGl2ZSBTb2Z0d2FyZSBHbWJIMR8wHQYDVQQLExZOZXR3 b3JrIEFkbWluaXN0cmF0aW9uMSIwIAYDVQQDExlJU0cgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRow GAYJKoZIhvcNAQkBFgtpbmZvQGlzZy5kZYIBADANBgkqhkiG9w0BAQQFAAOBgQAoJXnCqMVpxWXn Q2Oo/Jv8YHL5qeNyFMBmmWPMgt+ecjt1roE6hPpr22bny5nWgLaFgvQk6DptEOkmxFOmFLUDjQUA Rrypgr7Q5H3dILmsSKJPRWPiZPlwFtnA9Z7eSmnLbqF34kOmrt9NDPZxW/vx9fewVao2i0Fk0/n3 NpN0ETGCAh8wggIbAgEBMIHEMIG+MQswCQYDVQQGEwJERTEPMA0GA1UECBMGSGVzc2VuMRowGAYD VQQHExFGcmFua2Z1cnQgYW0gTWFpbjEhMB8GA1UEChMYSW5ub3ZhdGl2ZSBTb2Z0d2FyZSBHbWJI MR8wHQYDVQQLExZOZXR3b3JrIEFkbWluaXN0cmF0aW9uMSIwIAYDVQQDExlJU0cgQ2VydGlmaWNh dGUgQXV0aG9yaXR5MRowGAYJKoZIhvcNAQkBFgtpbmZvQGlzZy5kZQIBRzAJBgUrDgMCGgUAoIGx MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDEwNTE2NTA1Nlow IwYJKoZIhvcNAQkEMRYEFMG1VMv2oQ9huoOf2E79m3hZ7W5TMFIGCSqGSIb3DQEJDzFFMEMwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAMTE+Yg0t0/XRnOiw0D2VISwWOKjKKYnCkNdGHOkQWohJ +7uLlc1+pv6C/PK1JEcOM82l9ynE/ddOpcuKGdxPxujXc4uSq+kx/lAc+rWw7xSXUxxQpPjyVz9g oKDpnibM5P2dnVjyg0f7JZFUEILoPakkn/Rq8gG+VNvt2qr7RmM= --Boundary-02=_wXZ+/M91EO8KJ7L-- From erik@hensema.net Mon Jan 5 10:14:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 10:15:04 -0800 (PST) Received: from scrat.hensema.net (scrat.hensema.net [62.212.82.150]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05IEmTa004756 for ; Mon, 5 Jan 2004 10:14:48 -0800 Received: from dexter.hensema.net (cc78409-a.hnglo1.ov.home.nl [212.120.97.185]) by scrat.hensema.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id i05IEhuB007560; Mon, 5 Jan 2004 19:14:43 +0100 Received: from bender.home.hensema.net (root@bender.ipv6.hensema.net [IPv6:2001:888:10a1:0:202:44ff:fe69:60f5]) by dexter.hensema.net (8.12.7/8.12.7) with ESMTP id i05IEhB5001230; Mon, 5 Jan 2004 19:14:43 +0100 Received: from bender.home.hensema.net (erik@localhost [127.0.0.1]) by bender.home.hensema.net (8.12.7/8.12.7) with ESMTP id i05IEhMY013681; Mon, 5 Jan 2004 19:14:43 +0100 Received: (from erik@localhost) by bender.home.hensema.net (8.12.7/8.12.7/Submit) id i05IEghW013680; Mon, 5 Jan 2004 19:14:42 +0100 Date: Mon, 5 Jan 2004 19:14:42 +0100 From: Erik Hensema To: "David S. Miller" Cc: Linus Torvalds , netdev@oss.sgi.com Subject: Re: 2.6.0: something is leaking memory Message-ID: <20040105181442.GA13674@bender.home.hensema.net> Reply-To: erik@hensema.net References: <20040104204834.40b6ca51.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040104204834.40b6ca51.davem@redhat.com> User-Agent: Mutt/1.4i X-archive-position: 2224 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: erik@hensema.net Precedence: bulk X-list: netdev On Sun, Jan 04, 2004 at 08:48:34PM -0800, David S. Miller wrote: > On Sun, 4 Jan 2004 18:30:21 -0800 (PST) > Linus Torvalds wrote: > > > You've got 19 _megabytes_ allocated to "tcp6_sock", and they are all > > marked as "active". That's almost certainly the leaking bug. > > > > Everything else looks reasonably normal. > ... > > David? > > Fixed by changeset 1.1496.16.1 which is in 2.6.1-rc1 Are you sure? tcp6_sock 1110 1136 1024 4 1 : tunables 54 27 0 : slabdata 284 284 0 dexter:~ # netstat --inet6 | wc -l 21 dexter:~ # uptime 19:13:22 up 4:36, 1 user, load average: 0.02, 0.08, 0.09 This is 2.6.1-rc1. I can't say anything definitive until after a few days of uptime, but it sure seems the leak is still there. -- Erik Hensema (erik@hensema.net) From davem@pizda.ninka.net Mon Jan 5 11:08:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 11:08:37 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05J8OTa006485 for ; Mon, 5 Jan 2004 11:08:24 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id LAA19381; Mon, 5 Jan 2004 11:02:48 -0800 Date: Mon, 5 Jan 2004 11:02:48 -0800 From: "David S. Miller" To: Stefan Rompf Cc: mostrows@watson.ibm.com, netdev@oss.sgi.com Subject: Re: Deadlock in sungem/ip_auto_config/linkwatch Message-Id: <20040105110248.04ed06b7.davem@redhat.com> In-Reply-To: <200401051550.51063.srompf@isg.de> References: <1073307882.2041.98320.camel@brick.watson.ibm.com> <200401051550.51063.srompf@isg.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2225 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 5 Jan 2004 15:50:50 +0100 Stefan Rompf wrote: > Btw, what is the planned difference between rtnl_shlock() and rtnl_exlock()? > Even though the later is a null operation right now, I don't want to hold > more locks than needed in the linkwatch code. The idea was originally to make the RTNL semaphore a read-write one, but I doubt we'll ever make that happen and the shlock bits will just disappear entirely. From shemminger@osdl.org Mon Jan 5 11:11:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 11:11:29 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05JBETa006920 for ; Mon, 5 Jan 2004 11:11:15 -0800 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 i05JB3M26908; Mon, 5 Jan 2004 11:11:03 -0800 Date: Mon, 5 Jan 2004 11:10:59 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] multiple eth0 mixed PCI/ISA init Message-Id: <20040105111059.4a451146.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (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: 2226 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 This patch for 2.6 fixes the problem found by Zoltan Farkas with mixed PCI/ISA and a non-modular config. The problem is the old_netdev ISA probing isn't skipping "eth0" which already got assigned by the PCI initialization. diff -Nru a/drivers/net/Space.c b/drivers/net/Space.c --- a/drivers/net/Space.c Fri Dec 19 15:10:50 2003 +++ b/drivers/net/Space.c Fri Dec 19 15:10:50 2003 @@ -350,7 +350,7 @@ * Backwards compatibility - historically an I/O base of 1 was * used to indicate not to probe for this ethN interface */ - if (dev->base_addr == 1) { + if (__dev_get_by_name(dev->name) || dev->base_addr == 1) { free_netdev(dev); return -ENXIO; } From shemminger@osdl.org Mon Jan 5 12:17:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 12:17:23 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05KH6Ta010371 for ; Mon, 5 Jan 2004 12:17:06 -0800 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 i05KGsM11421; Mon, 5 Jan 2004 12:16:54 -0800 Date: Mon, 5 Jan 2004 12:16:54 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] convert /proc/net/packet to seq_file Message-Id: <20040105121654.3cfbdfb6.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (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: 2227 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 AF_PACKET's /proc interface to seq_file. No change in functionality, but does fix problem with refcounting on this proc interface. diff -Nru a/net/packet/af_packet.c b/net/packet/af_packet.c --- a/net/packet/af_packet.c Mon Jan 5 12:14:55 2004 +++ b/net/packet/af_packet.c Mon Jan 5 12:14:55 2004 @@ -64,6 +64,7 @@ #include #include #include +#include #include #include #include @@ -1767,61 +1768,86 @@ }; #ifdef CONFIG_PROC_FS -static int packet_read_proc(char *buffer, char **start, off_t offset, - int length, int *eof, void *data) +static inline struct sock *packet_seq_idx(loff_t off) { - off_t pos=0; - off_t begin=0; - int len=0; struct sock *s; struct hlist_node *node; - - len+= sprintf(buffer,"sk RefCnt Type Proto Iface R Rmem User Inode\n"); + sk_for_each(s, node, &packet_sklist) { + if (!off--) + return s; + } + return NULL; +} + +static void *packet_seq_start(struct seq_file *seq, loff_t *pos) +{ read_lock(&packet_sklist_lock); + return *pos ? packet_seq_idx(*pos - 1) : SEQ_START_TOKEN; +} - sk_for_each(s, node, &packet_sklist) { - struct packet_opt *po = pkt_sk(s); +static void *packet_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + ++*pos; + return (v == SEQ_START_TOKEN) + ? sk_head(&packet_sklist) + : sk_next((struct sock*)v) ; +} - len+=sprintf(buffer+len,"%p %-6d %-4d %04x %-5d %1d %-6u %-6u %-6lu", - s, - atomic_read(&s->sk_refcnt), - s->sk_type, - ntohs(po->num), - po->ifindex, - po->running, - atomic_read(&s->sk_rmem_alloc), - sock_i_uid(s), - sock_i_ino(s) - ); +static void packet_seq_stop(struct seq_file *seq, void *v) +{ + read_unlock(&packet_sklist_lock); +} - buffer[len++]='\n'; - - pos=begin+len; - if(posoffset+length) - goto done; +static int packet_seq_show(struct seq_file *seq, void *v) +{ + if (v == SEQ_START_TOKEN) + seq_puts(seq, "sk RefCnt Type Proto Iface R Rmem User Inode\n"); + else { + struct sock *s = v; + const struct packet_opt *po = pkt_sk(s); + + seq_printf(seq, + "%p %-6d %-4d %04x %-5d %1d %-6u %-6u %-6lu\n", + s, + atomic_read(&s->sk_refcnt), + s->sk_type, + ntohs(po->num), + po->ifindex, + po->running, + atomic_read(&s->sk_rmem_alloc), + sock_i_uid(s), + sock_i_ino(s) ); } - *eof = 1; -done: - read_unlock(&packet_sklist_lock); - *start=buffer+(offset-begin); - len-=(offset-begin); - if(len>length) - len=length; - if(len<0) - len=0; - return len; + return 0; } + +static struct seq_operations packet_seq_ops = { + .start = packet_seq_start, + .next = packet_seq_next, + .stop = packet_seq_stop, + .show = packet_seq_show, +}; + +static int packet_seq_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &packet_seq_ops); +} + +static struct file_operations packet_seq_fops = { + .owner = THIS_MODULE, + .open = packet_seq_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; + #endif static void __exit packet_exit(void) { - remove_proc_entry("net/packet", 0); + proc_net_remove("packet"); unregister_netdevice_notifier(&packet_netdev_notifier); sock_unregister(PF_PACKET); return; @@ -1831,9 +1857,8 @@ { sock_register(&packet_family_ops); register_netdevice_notifier(&packet_netdev_notifier); -#ifdef CONFIG_PROC_FS - create_proc_read_entry("net/packet", 0, 0, packet_read_proc, NULL); -#endif + proc_net_fops_create("packet", 0, &packet_seq_fops); + return 0; } From davem@pizda.ninka.net Mon Jan 5 13:00:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 13:00:46 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05L0VTa017002 for ; Mon, 5 Jan 2004 13:00:33 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA19770; Mon, 5 Jan 2004 12:54:56 -0800 Date: Mon, 5 Jan 2004 12:54:56 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] convert /proc/net/packet to seq_file Message-Id: <20040105125456.05acad7b.davem@redhat.com> In-Reply-To: <20040105121654.3cfbdfb6.shemminger@osdl.org> References: <20040105121654.3cfbdfb6.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2228 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 5 Jan 2004 12:16:54 -0800 Stephen Hemminger wrote: > Convert AF_PACKET's /proc interface to seq_file. No change in functionality, > but does fix problem with refcounting on this proc interface. Applied, thanks Stephen. From davem@pizda.ninka.net Mon Jan 5 13:02:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 13:02:46 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05L2XTa017414 for ; Mon, 5 Jan 2004 13:02:33 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA19825; Mon, 5 Jan 2004 12:56:59 -0800 Date: Mon, 5 Jan 2004 12:56:59 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] multiple eth0 mixed PCI/ISA init Message-Id: <20040105125659.56c2f6b5.davem@redhat.com> In-Reply-To: <20040105111059.4a451146.shemminger@osdl.org> References: <20040105111059.4a451146.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2229 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 5 Jan 2004 11:10:59 -0800 Stephen Hemminger wrote: > This patch for 2.6 fixes the problem found by Zoltan Farkas > with mixed PCI/ISA and a non-modular config. The problem is the old_netdev > ISA probing isn't skipping "eth0" which already got assigned by the PCI > initialization. Applied, thanks Stephen. From romieu@fr.zoreil.com Mon Jan 5 14:20:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 14:20:49 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05MKXTa020038 for ; Mon, 5 Jan 2004 14:20:34 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i05MHgsW023074; Mon, 5 Jan 2004 23:17:42 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i05MHf78023073; Mon, 5 Jan 2004 23:17:41 +0100 Date: Mon, 5 Jan 2004 23:17:41 +0100 From: Francois Romieu To: akpm@osdl.org Cc: netdev@oss.sgi.com, Jeff Garzik , Brad House Subject: [patch] 2.6.1-rc1-mm1 - typo of death in the r8169 driver Message-ID: <20040105231741.A19514@electric-eye.fr.zoreil.com> References: <20031122183001.GA16993@gtf.org> <20031124000939.A456@electric-eye.fr.zoreil.com> <20031126004550.A25408@electric-eye.fr.zoreil.com> <20031127235143.A16767@electric-eye.fr.zoreil.com> <20031130014738.A2589@electric-eye.fr.zoreil.com> <3FF846C3.5070207@mainstreetsoftworks.com> <20040104233849.A3214@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040104233849.A3214@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Sun, Jan 04, 2004 at 11:38:49PM +0100 X-Organisation: Land of Sunshine Inc. X-archive-position: 2230 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, silly bug in the r8169 driver. Please apply, thanks. -- Ueimor --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="r8169-rx-fill-typo.patch" Oops... drivers/net/r8169.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/r8169.c~r8169-rx-fill-typo drivers/net/r8169.c --- linux-2.6.1-rc1-mm1/drivers/net/r8169.c~r8169-rx-fill-typo 2004-01-05 22:55:24.000000000 +0100 +++ linux-2.6.1-rc1-mm1-fr/drivers/net/r8169.c 2004-01-05 23:03:39.000000000 +0100 @@ -1186,7 +1186,7 @@ static u32 rtl8169_rx_fill(struct rtl816 { u32 cur; - for (cur = start; end - start > 0; cur++) { + for (cur = start; end - cur > 0; cur++) { int ret, i = cur % NUM_RX_DESC; if (tp->Rx_skbuff[i]) _ --45Z9DzgjV8m4Oswq-- From romieu@fr.zoreil.com Mon Jan 5 14:40:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 14:40:49 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05MeZTa020774 for ; Mon, 5 Jan 2004 14:40:36 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i05McOsW023388; Mon, 5 Jan 2004 23:38:24 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i05McO19023387; Mon, 5 Jan 2004 23:38:24 +0100 Date: Mon, 5 Jan 2004 23:38:23 +0100 From: Francois Romieu To: "Krishnakumar. R" Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH] r8169 ethtool support. Message-ID: <20040105233823.B19514@electric-eye.fr.zoreil.com> References: <1073210391.3555.7.camel@l5ac210.l5.laser5.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1073210391.3555.7.camel@l5ac210.l5.laser5.co.jp>; from krishnakumar@naturesoft.net on Sun, Jan 04, 2004 at 06:59:51PM +0900 X-Organisation: Land of Sunshine Inc. X-archive-position: 2231 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Krishnakumar. R : [minimal ethtool for r8169] Added to the pile. -- Ueimor From davem@pizda.ninka.net Mon Jan 5 19:59:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 19:59:55 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i063xgTa007897 for ; Mon, 5 Jan 2004 19:59:42 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id TAA20708; Mon, 5 Jan 2004 19:54:03 -0800 Date: Mon, 5 Jan 2004 19:54:03 -0800 From: "David S. Miller" To: Jeff Garzik Cc: benh@kernel.crashing.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Problem with dev_kfree_skb_any() in 2.6.0 Message-Id: <20040105195403.65ac4e9e.davem@redhat.com> In-Reply-To: <20040102025807.GB3851@gtf.org> References: <1072567054.4112.14.camel@gaston> <20031227170755.4990419b.davem@redhat.com> <3FF0FA6A.8000904@pobox.com> <20031229205157.4c631f28.davem@redhat.com> <20031230051519.GA6916@gtf.org> <20031229220122.30078657.davem@redhat.com> <3FF11745.4060705@pobox.com> <20031229221345.31c8c763.davem@redhat.com> <3FF1B939.1090108@pobox.com> <20040101124218.258e8b73.davem@redhat.com> <20040102025807.GB3851@gtf.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2232 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, 1 Jan 2004 21:58:07 -0500 Jeff Garzik wrote: > On Thu, Jan 01, 2004 at 12:42:18PM -0800, David S. Miller wrote: > > Though, is there any particular reason you don't like adding a > > "|| irqs_disabled()" check to the if statement instead? > > I prefer that solution better actually. > > Yep, in fact when I wrote the above message, I came across a couple when I > was pondering... > * the destructor runs in a more predictable context. > * given the problem that started this thread, the 'if' test is a > potentially problematic area. Why not eliminate all possibility that > this problem will occur again? The way I see this, dev_kfree_skb_any() is not used in any performance critical path, so at worst during device shutdown, reset, or power-down, TX queue packet freeing work could be delayed by up to one jiffie. Therefore I've put the "|| irqs_disabled()" version of the fix into my tree. Thanks for working this out with me Jeff :) From jgarzik@pobox.com Mon Jan 5 23:54:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 23:54:18 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i067s2Ta016121 for ; Mon, 5 Jan 2004 23:54:05 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:42061 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1Adm2L-00075l-P2; Tue, 06 Jan 2004 07:54:01 +0000 Message-ID: <3FFA6981.7030006@pobox.com> Date: Tue, 06 Jan 2004 02:53:37 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: akpm@osdl.org, netdev@oss.sgi.com, Brad House Subject: Re: [patch] 2.6.1-rc1-mm1 - typo of death in the r8169 driver References: <20031122183001.GA16993@gtf.org> <20031124000939.A456@electric-eye.fr.zoreil.com> <20031126004550.A25408@electric-eye.fr.zoreil.com> <20031127235143.A16767@electric-eye.fr.zoreil.com> <20031130014738.A2589@electric-eye.fr.zoreil.com> <3FF846C3.5070207@mainstreetsoftworks.com> <20040104233849.A3214@electric-eye.fr.zoreil.com> <20040105231741.A19514@electric-eye.fr.zoreil.com> In-Reply-To: <20040105231741.A19514@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2234 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 applied From jgarzik@pobox.com Mon Jan 5 23:53:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 23:54:09 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i067rtTa016116 for ; Mon, 5 Jan 2004 23:53:56 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:42060 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1Adm2E-00075k-3g; Tue, 06 Jan 2004 07:53:54 +0000 Message-ID: <3FFA6978.3080509@pobox.com> Date: Tue, 06 Jan 2004 02:53:28 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Feldman, Scott" CC: netdev@oss.sgi.com, cramerj@intel.com Subject: Re: [e1000 2.6-exp] back out CSA interrupt fix References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2233 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 applied From jgarzik@pobox.com Tue Jan 6 00:04:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 00:04:54 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0684ZTa017071 for ; Tue, 6 Jan 2004 00:04:36 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:42077 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AdmCY-0007DO-Ey; Tue, 06 Jan 2004 08:04:34 +0000 Message-ID: <3FFA6BFB.6020100@pobox.com> Date: Tue, 06 Jan 2004 03:04:11 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Amir Noam CC: Jay Vosburgh , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH 1/3] [bonding 2.6] Save parameters in a per-bond data structure References: <200401051729.52769.amir.noam@intel.com> In-Reply-To: <200401051729.52769.amir.noam@intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2235 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 applied 1-3 to 2.6.x From jgarzik@pobox.com Tue Jan 6 00:06:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 00:07:15 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0686wTa017590 for ; Tue, 6 Jan 2004 00:06:59 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:42083 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AdmEr-0007FD-T9; Tue, 06 Jan 2004 08:06:58 +0000 Message-ID: <3FFA6C8B.1030203@pobox.com> Date: Tue, 06 Jan 2004 03:06:35 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Amir Noam CC: Jay Vosburgh , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH 1/3] [bonding 2.4] Save parameters in a per-bond data structure References: <200401051726.33613.amir.noam@intel.com> In-Reply-To: <200401051726.33613.amir.noam@intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2236 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 applied 1-3 to 2.4.x From hibi665@oki.com Tue Jan 6 04:14:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 04:14:29 -0800 (PST) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06CE3Ta029826 for ; Tue, 6 Jan 2004 04:14:04 -0800 Received: from aoi.okilab.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id VAA18491 for ; Tue, 6 Jan 2004 21:14:02 +0900 Received: (qmail 18745 invoked from network); 6 Jan 2004 21:14:00 +0900 Received: from dhcp23233.okilab.oki.co.jp (HELO kiso) (172.24.23.233) by aoi.okilab.oki.co.jp with SMTP; 6 Jan 2004 21:14:00 +0900 Message-Id: <20040106211542.4fe9e531%hibi665@oki.com> MIME-Version: 1.0 Date: Tue, 06 Jan 2004 21:15:42 +0900 X-Mailer: Denshin 8 Go V32.1.4.3 X-My-Real-Login-Name: thibi; aoi From: Takashi Hibi To: netdev@oss.sgi.com Subject: MLD problems (again) X-archive-position: 2237 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hibi665@oki.com Precedence: bulk X-list: netdev A Happy new year. Let me discuss about the problems of MLD again. As I pointed out, there are two problems in current MLD code. 1. In MLDv1 compatibility mode, Older Version Querier Present timer expires prematurely. 2. After join SSM using setsockopt(MCAST_JOIN_SOURCE_GROUP), MLDv2 listener report isn't issued immediately. The cause of 1 is the wrong computation of timeout value. The cause of 2 is difficult to find. After tracing the code, I figured out that the mode of ifmcaddr6 isn't correctly set after setsockopt. After join by setsockopt, pmc->mca_sfmode should be MCAST_INCLUDE, but it remains MCAST_EXCLUDE. Eventually is_in() call returns false, and MLDv2 packet isn't composed. I don't know the right way to fix it, since the code is too complicated by a lot of flags. At least the following patch(diff from 2.6.0) works for me. Regards, Takashi Hibi --- mcast.c 2003-12-18 11:59:28.000000000 +0900 +++ new/mcast.c 2004-01-06 16:30:05.546174486 +0900 @@ -1050,7 +1050,7 @@ int igmp6_event_query(struct sk_buff *sk /* Translate milliseconds to jiffies */ max_delay = (ntohs(hdr->icmp6_maxdelay)*HZ)/1000; - switchback = (idev->mc_qrv + 1) * max_delay; + switchback = MLD_QRV_DEFAULT * 125*HZ + max_delay; idev->mc_v1_seen = jiffies + switchback; /* cancel the interface change timer */ @@ -1541,7 +1541,8 @@ static void mld_send_cr(struct inet6_dev type = MLD2_CHANGE_TO_EXCLUDE; else type = MLD2_CHANGE_TO_INCLUDE; - skb = add_grec(skb, pmc, type, 0, 0); + if (!skb) + skb = add_grec(skb, pmc, type, 0, 0); } spin_unlock_bh(&pmc->mca_lock); } @@ -1745,6 +1746,7 @@ static int ip6_mc_add1_src(struct ifmcad return -ENOBUFS; memset(psf, 0, sizeof(*psf)); psf->sf_addr = *psfsrc; + psf->sf_crcount = pmc->idev->mc_qrv; if (psf_prev) { psf_prev->sf_next = psf; } else @@ -1799,6 +1801,7 @@ int ip6_mc_add_src(struct inet6_dev *ide struct ifmcaddr6 *pmc; int isexclude; int i, err; + int first_join_src_grp; if (!idev) return -ENODEV; @@ -1816,6 +1819,8 @@ int ip6_mc_add_src(struct inet6_dev *ide sf_markstate(pmc); isexclude = pmc->mca_sfmode == MCAST_EXCLUDE; + first_join_src_grp = (!pmc->sources && sfmode == MCAST_INCLUDE && + sfcount == 1 && delta); if (!delta) pmc->mca_sfcount[sfmode]++; err = 0; @@ -1827,10 +1832,19 @@ int ip6_mc_add_src(struct inet6_dev *ide if (err) { int j; - pmc->mca_sfcount[sfmode]--; + if (!delta) + pmc->mca_sfcount[sfmode]--; for (j=0; jmca_sfcount[MCAST_EXCLUDE] != 0)) { + goto done; + } + if (first_join_src_grp) { + pmc->mca_sfmode = MCAST_INCLUDE; + if (sf_setstate(pmc)) + mld_ifc_event(idev); + goto done; + } + if (isexclude != (pmc->mca_sfcount[MCAST_EXCLUDE] != 0)) { struct inet6_dev *idev = pmc->idev; struct ip6_sf_list *psf; @@ -1848,6 +1862,7 @@ int ip6_mc_add_src(struct inet6_dev *ide mld_ifc_event(idev); } else if (sf_setstate(pmc)) mld_ifc_event(idev); +done: spin_unlock_bh(&pmc->mca_lock); read_unlock_bh(&idev->lock); return err; From cmadams@hiwaay.net Tue Jan 6 07:17:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 07:18:07 -0800 (PST) Received: from mail.hiwaay.net (bee.hiwaay.net [216.180.54.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06FHrTa007362 for ; Tue, 6 Jan 2004 07:17:53 -0800 Received: from bee.hiwaay.net (localhost [127.0.0.1]) by mail.hiwaay.net (8.12.10/8.12.10) with ESMTP id i06FHqu51538440 for ; Tue, 6 Jan 2004 09:17:52 -0600 (CST) Received: (from cmadams@localhost) by bee.hiwaay.net (8.12.10/8.12.10/DefSubmit) id i06FHq5Z1538608 for netdev@oss.sgi.com; Tue, 6 Jan 2004 09:17:52 -0600 (CST) Date: Tue, 6 Jan 2004 09:17:51 -0600 From: Chris Adams To: netdev@oss.sgi.com Subject: Problem with Compaq NC3131 dual eth card Message-ID: <20040106151751.GB1509622@hiwaay.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 2238 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cmadams@hiwaay.net Precedence: bulk X-list: netdev I have a Compaq NC3131 dual 10/100 ethernet PCI (64/32 bit in a 32 bit slot) card. The e100 module doesn't work, and the eepro100 module can be coerced to work but complains about it (this is with Fedora Core 1 and kernel-2.4.22-1.2135.nptl.athlon.rpm). The e100 module prints: ************************************************************************ Intel(R) PRO/100 Network Driver - version 2.3.18-k1 Copyright (c) 2003 Intel Corporation divert: allocating divert_blk for eth1 e100: selftest OK. e100: Invalid Ethernet address e100: Failed to initialize, instance #0 divert: freeing divert_blk for eth1 divert: allocating divert_blk for eth1 e100: selftest OK. e100: Invalid Ethernet address e100: Failed to initialize, instance #0 divert: freeing divert_blk for eth1 ************************************************************************ and unloads itself immediately. The eepro100 module prints: ************************************************************************ eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin and others divert: allocating divert_blk for eth1 eth1: Invalid EEPROM checksum 0xffc0, check settings before activating this device! eth1: OEM i82557/i82558 10/100 Ethernet, FF:FF:FF:FF:FF:FF, IRQ 11. Board assembly ffffff-255, Physical connectors present: RJ45 BNC AUI MII Primary interface chip unknown-15 PHY #31. Secondary interface chip i82555. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x24c9f043). divert: allocating divert_blk for eth2 eth2: Invalid EEPROM checksum 0xffc0, check settings before activating this device! eth2: OEM i82557/i82558 10/100 Ethernet, FF:FF:FF:FF:FF:FF, IRQ 10. Board assembly ffffff-255, Physical connectors present: RJ45 BNC AUI MII Primary interface chip unknown-15 PHY #31. Secondary interface chip i82555. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x24c9f043). ************************************************************************ It will load and let me configure the devices. If I force it to a different MAC address (reusing the MAC from eth0 and moving the wire to avoid ARP problems), it seems to work, but I shouldn't have to do that. Is my card defective or is this a compatibility problem? Is there a way to fix this? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From erik@hensema.net Tue Jan 6 07:59:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 07:59:56 -0800 (PST) Received: from scrat.hensema.net (scrat.hensema.net [62.212.82.150]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06FxeTa009012 for ; Tue, 6 Jan 2004 07:59:41 -0800 Received: from dexter.hensema.net (cc78409-a.hnglo1.ov.home.nl [212.120.97.185]) by scrat.hensema.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id i06FxYng008547; Tue, 6 Jan 2004 16:59:34 +0100 Received: from bender.home.hensema.net (root@bender.ipv6.hensema.net [IPv6:2001:888:10a1:0:202:44ff:fe69:60f5]) by dexter.hensema.net (8.12.7/8.12.7) with ESMTP id i06FxYB5022646; Tue, 6 Jan 2004 16:59:34 +0100 Received: from bender.home.hensema.net (erik@localhost [127.0.0.1]) by bender.home.hensema.net (8.12.7/8.12.7) with ESMTP id i06FxY72003383; Tue, 6 Jan 2004 16:59:34 +0100 Received: (from erik@localhost) by bender.home.hensema.net (8.12.7/8.12.7/Submit) id i06FxYVT003382; Tue, 6 Jan 2004 16:59:34 +0100 Date: Tue, 6 Jan 2004 16:59:34 +0100 From: Erik Hensema To: "David S. Miller" Cc: Linus Torvalds , netdev@oss.sgi.com Subject: Re: 2.6.0: something is leaking memory Message-ID: <20040106155933.GA3373@bender.home.hensema.net> Reply-To: erik@hensema.net References: <20040104204834.40b6ca51.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040104204834.40b6ca51.davem@redhat.com> User-Agent: Mutt/1.4i X-archive-position: 2239 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: erik@hensema.net Precedence: bulk X-list: netdev On Sun, Jan 04, 2004 at 08:48:34PM -0800, David S. Miller wrote: > On Sun, 4 Jan 2004 18:30:21 -0800 (PST) > Linus Torvalds wrote: > > > You've got 19 _megabytes_ allocated to "tcp6_sock", and they are all > > marked as "active". That's almost certainly the leaking bug. > > > > Everything else looks reasonably normal. > ... > > David? > > Fixed by changeset 1.1496.16.1 which is in 2.6.1-rc1 The leak seems to be in 2.6.1-rc1 too and I can't find any IPv6 related fixes wrt memory in the long format changelog of 2.6.1-rc1. David: are you sure it was fixed in rc1? It doesn't seem to be in -rc2 either. This is after 26 hours uptime: tcp6_sock 6246 6248 1024 4 1 : tunables 54 27 0 : slabdata 1562 1562 0 -- Erik Hensema (erik@hensema.net) From jmorris@redhat.com Tue Jan 6 08:01:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 08:01:25 -0800 (PST) Received: from thoron.boston.redhat.com (nat-pool-bos.redhat.com [66.187.230.200]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06G1ATa009420 for ; Tue, 6 Jan 2004 08:01:10 -0800 Received: from thoron.boston.redhat.com (localhost.localdomain [127.0.0.1]) by thoron.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i06G13iF007581; Tue, 6 Jan 2004 11:01:03 -0500 Received: from localhost (jmorris@localhost) by thoron.boston.redhat.com (8.12.8/8.12.8/Submit) with ESMTP id i06G130N007577; Tue, 6 Jan 2004 11:01:03 -0500 X-Authentication-Warning: thoron.boston.redhat.com: jmorris owned process doing -bs Date: Tue, 6 Jan 2004 11:01:03 -0500 (EST) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: netdev@oss.sgi.com cc: netfilter-devel@lists.netfilter.org, "David S. Miller" , Stephen Smalley Subject: [RFC] IPv4 Netfilter hook priorities for SELinux Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2240 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev SELinux needs to use some Netfilter hooks, and I'd like to propose the hook priorities below for the mainline kernel. As SELinux is a mandatory access control system, it needs to be able to look at packets before and after they may have been modified. Two priorities are thus required. The SELINUX_LAST priority is straightforward: this is after all mangling and NAT has occurred. The SELINUX_FIRST priority needs to be located before any packet modification hooks, although it is also potentially useful if located prior to conntrack so that SELinux has an opportunity to reject packets before they enter the conntrack code. Does anyone have any objections to the patch below (which I'd propose for 2.6.2), or other comments? - James -- James Morris diff -urN -X dontdiff linux-2.6.1-rc1-mm2.pending/include/linux/netfilter_ipv4.h linux-2.6.1-rc1-mm2.w1/include/linux/netfilter_ipv4.h --- linux-2.6.1-rc1-mm2.pending/include/linux/netfilter_ipv4.h 2003-09-27 20:50:51.000000000 -0400 +++ linux-2.6.1-rc1-mm2.w1/include/linux/netfilter_ipv4.h 2004-01-06 10:14:59.503138800 -0500 @@ -51,6 +51,7 @@ enum nf_ip_hook_priorities { NF_IP_PRI_FIRST = INT_MIN, + NF_IP_PRI_SELINUX_FIRST = -225, NF_IP_PRI_CONNTRACK = -200, NF_IP_PRI_BRIDGE_SABOTAGE_FORWARD = -175, NF_IP_PRI_MANGLE = -150, @@ -58,6 +59,7 @@ NF_IP_PRI_BRIDGE_SABOTAGE_LOCAL_OUT = -50, NF_IP_PRI_FILTER = 0, NF_IP_PRI_NAT_SRC = 100, + NF_IP_PRI_SELINUX_LAST = 225, NF_IP_PRI_LAST = INT_MAX, }; From shmulik.hen@intel.com Tue Jan 6 09:04:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 09:04:51 -0800 (PST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06H4bTa014309 for ; Tue, 6 Jan 2004 09:04:38 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.12 2003/12/18 18:58:11 root Exp $) with ESMTP id i05FCB5B005806; Mon, 5 Jan 2004 15:12:11 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i05FA309011452; Mon, 5 Jan 2004 15:10:03 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.220.54]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010507105104609 ; Mon, 05 Jan 2004 07:10:51 -0800 From: Shmuel Hen Organization: Intel Corporation Subject: Fwd: [bonding] trivial - Update comment blocks and version field Date: Mon, 5 Jan 2004 17:10:49 +0200 User-Agent: KMail/1.5.3 To: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401051710.50622.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2241 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 ---------- Forwarded Message ---------- Subject: [bonding] trivial - Update comment blocks and version field Date: Monday 05 January 2004 16:41 From: Shmuel Hen To: "Jeff Garzik" Cc: "Jay Vosburgh" , "Shmulik Hen" , "Amir Noam" , "Noam Marom" Update comment blocks, version field and copyright years to match all the recent changes that were accepted into 2.4/2.6. Applies on top of latest netdev BK tree. -- Shmulik. diff -Nuarp a/Documentation/networking/ifenslave.c b/Documentation/networking/ifenslave.c --- a/Documentation/networking/ifenslave.c Mon Jan 5 15:40:57 2004 +++ b/Documentation/networking/ifenslave.c Mon Jan 5 16:34:13 2004 @@ -89,13 +89,13 @@ * while it is running. It was already set during enslave. To * simplify things, it is now handeled separately. * - * - 2003/09/24 - Shmulik Hen + * - 2003/12/01 - Shmulik Hen * - Code cleanup and style changes * set version to 1.1.0 */ #define APP_VERSION "1.1.0" -#define APP_RELDATE "Septemer 24, 2003" +#define APP_RELDATE "December 1, 2003" #define APP_NAME "ifenslave" static char *version = diff -Nuarp a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c --- a/drivers/net/bonding/bond_3ad.c Mon Jan 5 15:40:57 2004 +++ b/drivers/net/bonding/bond_3ad.c Mon Jan 5 16:34:13 2004 @@ -1,5 +1,5 @@ /* - * Copyright(c) 1999 - 2003 Intel Corporation. All rights reserved. + * Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. * * 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 @@ -48,7 +48,7 @@ * problem on very high Tx traffic load where packets may get dropped * by the slave. * - * 2003/09/24 - Shmulik Hen + * 2003/12/01 - Shmulik Hen * - Code cleanup and style changes */ diff -Nuarp a/drivers/net/bonding/bond_3ad.h b/drivers/net/bonding/bond_3ad.h --- a/drivers/net/bonding/bond_3ad.h Mon Jan 5 15:40:57 2004 +++ b/drivers/net/bonding/bond_3ad.h Mon Jan 5 16:34:13 2004 @@ -1,5 +1,5 @@ /* - * Copyright(c) 1999 - 2003 Intel Corporation. All rights reserved. + * Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. * * 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 @@ -29,7 +29,7 @@ * - Renamed bond_3ad_link_status_changed() to * bond_3ad_handle_link_change() for compatibility with TLB. * - * 2003/09/24 - Shmulik Hen + * 2003/12/01 - Shmulik Hen * - Code cleanup and style changes */ diff -Nuarp a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c --- a/drivers/net/bonding/bond_alb.c Mon Jan 5 15:40:57 2004 +++ b/drivers/net/bonding/bond_alb.c Mon Jan 5 16:34:13 2004 @@ -1,5 +1,5 @@ /* - * Copyright(c) 1999 - 2003 Intel Corporation. All rights reserved. + * Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. * * 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 @@ -29,8 +29,11 @@ * - Add support for setting bond's MAC address with special * handling required for ALB/TLB. * - * 2003/09/24 - Shmulik Hen + * 2003/12/01 - Shmulik Hen * - Code cleanup and style changes + * + * 2003/12/30 - Amir Noam + * - Fixed: Cannot remove and re-enslave the original active slave. */ //#define BONDING_DEBUG 1 diff -Nuarp a/drivers/net/bonding/bond_alb.h b/drivers/net/bonding/bond_alb.h --- a/drivers/net/bonding/bond_alb.h Mon Jan 5 15:40:57 2004 +++ b/drivers/net/bonding/bond_alb.h Mon Jan 5 16:34:14 2004 @@ -1,5 +1,5 @@ /* - * Copyright(c) 1999 - 2003 Intel Corporation. All rights reserved. + * Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. * * 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 @@ -25,7 +25,7 @@ * - Add support for setting bond's MAC address with special * handling required for ALB/TLB. * - * 2003/09/24 - Shmulik Hen + * 2003/12/01 - Shmulik Hen * - Code cleanup and style changes */ diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Mon Jan 5 15:40:57 2004 +++ b/drivers/net/bonding/bond_main.c Mon Jan 5 16:34:14 2004 @@ -452,6 +452,12 @@ * o Change struct member names and types. * o Chomp trailing spaces, remove empty lines, fix indentations. * o Re-organize code according to context. + * + * 2003/12/30 - Amir Noam + * - Fixed: Cannot remove and re-enslave the original active slave. + * - Fixed: Releasing the original active slave causes mac address duplication. + * - Add support for slaves that use ethtool_ops. + * Set version to 2.5.3. */ //#define BONDING_DEBUG 1 diff -Nuarp a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h --- a/drivers/net/bonding/bonding.h Mon Jan 5 15:40:57 2004 +++ b/drivers/net/bonding/bonding.h Mon Jan 5 16:34:14 2004 @@ -23,7 +23,7 @@ * 2003/05/01 - Shmulik Hen * - Added support for Transmit load balancing mode. * - * 2003/09/24 - Shmulik Hen + * 2003/12/01 - Shmulik Hen * - Code cleanup and style changes */ @@ -36,8 +36,8 @@ #include "bond_3ad.h" #include "bond_alb.h" -#define DRV_VERSION "2.5.0" -#define DRV_RELDATE "December 1, 2003" +#define DRV_VERSION "2.5.3" +#define DRV_RELDATE "December 30, 2003" #define DRV_NAME "bonding" #define DRV_DESCRIPTION "Ethernet Channel Bonding Driver" diff -Nuarp a/include/linux/if_bonding.h b/include/linux/if_bonding.h --- a/include/linux/if_bonding.h Mon Jan 5 15:40:57 2004 +++ b/include/linux/if_bonding.h Mon Jan 5 16:34:14 2004 @@ -32,6 +32,9 @@ * 2003/05/01 - Amir Noam * - Added ABI version control to restore compatibility between * new/old ifenslave and new/old bonding. + * + * 2003/12/01 - Shmulik Hen + * - Code cleanup and style changes */ #ifndef _LINUX_IF_BONDING_H @@ -86,7 +89,7 @@ typedef struct ifbond { typedef struct ifslave { __s32 slave_id; /* Used as an IN param to the BOND_SLAVE_INFO_QUERY ioctl */ - __s8 slave_name[IFNAMSIZ]; + char slave_name[IFNAMSIZ]; __s8 link; __s8 state; __u32 link_failure_count; From davem@pizda.ninka.net Tue Jan 6 10:05:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 10:05:28 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06I5DTa016645 for ; Tue, 6 Jan 2004 10:05:13 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id JAA02701; Tue, 6 Jan 2004 09:59:09 -0800 Date: Tue, 6 Jan 2004 09:59:09 -0800 From: "David S. Miller" To: erik@hensema.net Cc: torvalds@osdl.org, netdev@oss.sgi.com, acme@conectiva.com.br Subject: Re: 2.6.0: something is leaking memory Message-Id: <20040106095909.7243b2ce.davem@redhat.com> In-Reply-To: <20040106155933.GA3373@bender.home.hensema.net> References: <20040104204834.40b6ca51.davem@redhat.com> <20040106155933.GA3373@bender.home.hensema.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2242 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, 6 Jan 2004 16:59:34 +0100 Erik Hensema wrote: > David: are you sure it was fixed in rc1? > > It doesn't seem to be in -rc2 either. > > This is after 26 hours uptime: > > tcp6_sock 6246 6248 1024 4 1 : tunables 54 27 0 > : slabdata 1562 1562 0 Someone mentioned about a bug in the userland program you're using that is openning these sockets? Something about leaving sockets not closed. (Arnaldo, we aparently still have a TCP ipv6 socket leak...) From mroos@tartutest.cyber.ee Tue Jan 6 10:13:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 10:13:53 -0800 (PST) Received: from tartutest.cyber.ee (tartutest.cyber.ee [193.40.6.70]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06IDbTa017156 for ; Tue, 6 Jan 2004 10:13:38 -0800 Received: Message by Barricade tartutest.cyber.ee with ESMTP id i06IRnEw021613; Tue, 6 Jan 2004 20:27:49 +0200 Received: from mroos by rhn.tartu-labor with local (Exim 4.30) id 1Advho-0000Pq-3c; Tue, 06 Jan 2004 20:13:28 +0200 From: Meelis Roos To: cmadams@hiwaay.net, netdev@oss.sgi.com Subject: Re: Problem with Compaq NC3131 dual eth card In-Reply-To: <20040106151751.GB1509622@hiwaay.net> User-Agent: tin/1.7.4-20031226 ("Taransay") (UNIX) (Linux/2.4.25-pre4 (i686)) Message-Id: Date: Tue, 06 Jan 2004 20:13:28 +0200 X-archive-position: 2243 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mroos@linux.ee Precedence: bulk X-list: netdev CA> I have a Compaq NC3131 dual 10/100 ethernet PCI (64/32 bit in a 32 bit CA> slot) card. The e100 module doesn't work, and the eepro100 module can CA> be coerced to work but complains about it (this is with Fedora Core 1 CA> and kernel-2.4.22-1.2135.nptl.athlon.rpm). FWIW, I have a NC3134 (64/66 in 32/33 slot). Just tested it with 2.6.1-rc1 and 2.4.25-pre4, works fine and transfers fine. I tried only e100 since it just worked. -- Meelis Roos From acme@conectiva.com.br Tue Jan 6 10:53:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 10:53:28 -0800 (PST) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06IrCTa018239 for ; Tue, 6 Jan 2004 10:53:13 -0800 Received: from 200-103-242-110.ctame7042.dsl.brasiltelecom.net.br ([200.103.242.110] helo=oops.kerneljanitors.org) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1AdwRH-0004eH-00; Tue, 06 Jan 2004 17:00:27 -0200 Received: by oops.kerneljanitors.org (Postfix, from userid 500) id D7A851966D; Tue, 6 Jan 2004 17:03:58 -0200 (BRDT) Date: Tue, 6 Jan 2004 17:03:58 -0200 From: Arnaldo Carvalho de Melo To: "David S. Miller" Cc: erik@hensema.net, torvalds@osdl.org, netdev@oss.sgi.com Subject: Re: 2.6.0: something is leaking memory Message-ID: <20040106190358.GV28868@conectiva.com.br> References: <20040104204834.40b6ca51.davem@redhat.com> <20040106155933.GA3373@bender.home.hensema.net> <20040106095909.7243b2ce.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040106095909.7243b2ce.davem@redhat.com> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.5.1i X-archive-position: 2244 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Em Tue, Jan 06, 2004 at 09:59:09AM -0800, David S. Miller escreveu: > On Tue, 6 Jan 2004 16:59:34 +0100 > Erik Hensema wrote: > > > David: are you sure it was fixed in rc1? > > > > It doesn't seem to be in -rc2 either. > > > > This is after 26 hours uptime: > > > > tcp6_sock 6246 6248 1024 4 1 : tunables 54 27 0 > > : slabdata 1562 1562 0 > > Someone mentioned about a bug in the userland program you're > using that is openning these sockets? Something about leaving sockets > not closed. > > (Arnaldo, we aparently still have a TCP ipv6 socket leak...) I'll take a look at this. From uucp@coruscant.gnumonks.org Tue Jan 6 11:16:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 11:16:49 -0800 (PST) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06JGWTa019311 for ; Tue, 6 Jan 2004 11:16:34 -0800 Received: from uucp by coruscant.gnumonks.org with local-bsmtp (Exim 4.20) id 1Adwgo-0001Fb-TA for netdev@oss.sgi.com; Tue, 06 Jan 2004 20:16:30 +0100 Received: from laforge by obroa-skai.gnumonks.org with local (Exim 3.36 #1) id 1Adwdb-0000Ob-00; Tue, 06 Jan 2004 20:13:11 +0100 Date: Tue, 6 Jan 2004 20:13:11 +0100 From: Harald Welte To: James Morris Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, "David S. Miller" , Stephen Smalley Subject: Re: [RFC] IPv4 Netfilter hook priorities for SELinux Message-ID: <20040106191311.GH934@obroa-skai.de.gnumonks.org> Mail-Followup-To: Harald Welte , James Morris , netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, "David S. Miller" , Stephen Smalley References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U3s59FfKcByyGl+j" Content-Disposition: inline In-Reply-To: X-Operating-System: Linux obroa-skai.de.gnumonks.org 2.6.0-test11 X-Date: Today is Sweetmorn, the 6th day of Chaos in the YOLD 3170 User-Agent: Mutt/1.5.4i X-archive-position: 2245 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 --U3s59FfKcByyGl+j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 06, 2004 at 11:01:03AM -0500, James Morris wrote: =20 > Does anyone have any objections to the patch below (which I'd propose for= =20 > 2.6.2), or other comments? Thanks James, I am perfectly fine with your patch. Feel free to put them into netfilter_arp.h and netfilter_ipv6.h, too. > - James --=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 --U3s59FfKcByyGl+j Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/+wjGXaXGVTD0i/8RAjFRAJ9Mub15xR+99zCM+eZgCi04/P3XCACeLCmI B9EEK83mrXSiQN6i549VcP4= =vGvz -----END PGP SIGNATURE----- --U3s59FfKcByyGl+j-- From erik@hensema.net Tue Jan 6 11:36:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 11:36:48 -0800 (PST) Received: from scrat.hensema.net (scrat.hensema.net [62.212.82.150]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06JaWTa020184 for ; Tue, 6 Jan 2004 11:36:33 -0800 Received: from dexter.hensema.net (cc78409-a.hnglo1.ov.home.nl [212.120.97.185]) by scrat.hensema.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id i06JaGng021881; Tue, 6 Jan 2004 20:36:16 +0100 Received: from bender.home.hensema.net (root@bender.ipv6.hensema.net [IPv6:2001:888:10a1:0:202:44ff:fe69:60f5]) by dexter.hensema.net (8.12.7/8.12.7) with ESMTP id i06JaGB5016752; Tue, 6 Jan 2004 20:36:16 +0100 Received: from bender.home.hensema.net (erik@localhost [127.0.0.1]) by bender.home.hensema.net (8.12.7/8.12.7) with ESMTP id i06JaG72004558; Tue, 6 Jan 2004 20:36:16 +0100 Received: (from erik@localhost) by bender.home.hensema.net (8.12.7/8.12.7/Submit) id i06JaFWv004557; Tue, 6 Jan 2004 20:36:15 +0100 Date: Tue, 6 Jan 2004 20:36:15 +0100 From: Erik Hensema To: "David S. Miller" Cc: torvalds@osdl.org, netdev@oss.sgi.com, acme@conectiva.com.br Subject: Re: 2.6.0: something is leaking memory Message-ID: <20040106193615.GA4544@bender.home.hensema.net> Reply-To: erik@hensema.net References: <20040104204834.40b6ca51.davem@redhat.com> <20040106155933.GA3373@bender.home.hensema.net> <20040106095909.7243b2ce.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040106095909.7243b2ce.davem@redhat.com> User-Agent: Mutt/1.4i X-archive-position: 2246 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: erik@hensema.net Precedence: bulk X-list: netdev On Tue, Jan 06, 2004 at 09:59:09AM -0800, David S. Miller wrote: > On Tue, 6 Jan 2004 16:59:34 +0100 > Erik Hensema wrote: > > > David: are you sure it was fixed in rc1? > > > > It doesn't seem to be in -rc2 either. > > > > This is after 26 hours uptime: > > > > tcp6_sock 6246 6248 1024 4 1 : tunables 54 27 0 > > : slabdata 1562 1562 0 > > Someone mentioned about a bug in the userland program you're > using that is openning these sockets? Something about leaving sockets > not closed. That's correct. I suspect that this exposes the leak in the kernel more promimently than on other systems. The leak is in nscd, it doesn't properly close sockets to my LDAP server. This is not a kernel problem I think, because it also leaks in 2.4.x. The kernelspace leak however is not in 2.4, only in 2.6. I'm restarting nscd in cron every night, which makes the CLOSE_WAIT sockets go away. However the kernel resources are not freed it seems. -- Erik Hensema (erik@hensema.net) From scott.feldman@intel.com Tue Jan 6 11:43:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 11:44:09 -0800 (PST) Received: from petasus.ch.intel.com (petasus.ch.intel.com [143.182.124.5]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06JhsTa020748 for ; Tue, 6 Jan 2004 11:43:55 -0800 Received: from azsmsxvs040.ch.intel.com (azsmsxvs040.ch.intel.com [10.2.248.11]) by petasus.ch.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.6 2003/12/18 18:58:11 root Exp $) with SMTP id i06JgfhD022754; Tue, 6 Jan 2004 19:43:43 GMT Received: from azsmsx331-2.ch.intel.com ([10.2.161.41]) by azsmsxvs040.ch.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010612434326281 ; Tue, 06 Jan 2004 12:43:43 -0700 Received: from rrsmsx401.amr.corp.intel.com ([10.14.9.74]) by azsmsx331-2.ch.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 6 Jan 2004 12:43:43 -0700 Received: from orsmsx312.amr.corp.intel.com ([192.168.65.62]) by rrsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 6 Jan 2004 12:43:41 -0700 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 6 Jan 2004 11:43:39 -0800 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: Problem with Compaq NC3131 dual eth card Date: Tue, 6 Jan 2004 11:43:39 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Problem with Compaq NC3131 dual eth card Thread-Index: AcPUaFn0UwQhJlULT5e6luJhURXDwAAIPwwg From: "Feldman, Scott" To: "Chris Adams" , X-OriginalArrivalTime: 06 Jan 2004 19:43:39.0668 (UTC) FILETIME=[62081540:01C3D48D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i06JhsTa020748 X-archive-position: 2247 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 > eth1: OEM i82557/i82558 10/100 Ethernet, FF:FF:FF:FF:FF:FF, IRQ 11. [snip] > eth2: Invalid EEPROM checksum 0xffc0, check settings before > activating this device! You're EEPROM image is invalid - looks like it's all 0xFFs - verify with ethtool -e ethX. The first three words of the EEPROM should be the MAC address. e100 errors out because it wants a valid MAC address. > Is my card defective or is this a compatibility problem? Is > there a way to fix this? Get another nic or reprogram the EEPROM in this one. Ok, so you want to reprogram the eeprom? This isn't going to be pretty: 1) get a good image from a like-NC3131-nic using ethtool -e eth; 2) modify e100 to skip the check for valid MAC address and valid checksum so the driver will load; 3) run ethtool -E eth magic 4660 offset value , where x is your interface, y is the byte offset, and z is byte value to write. You can do this by hand, or write a script to parse the output from ethtool -e; 4) revert e100 back to original Told you it wasn't pretty. Maybe someone could write a little script to # ethtool -e eth0 | up_eeprom eth1 Enter unique MAC address: 00:A0:45:78:90:02 -scott From jmorris@redhat.com Tue Jan 6 12:38:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 12:38:50 -0800 (PST) Received: from thoron.boston.redhat.com (nat-pool-bos.redhat.com [66.187.230.200]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06KcZTa024982 for ; Tue, 6 Jan 2004 12:38:35 -0800 Received: from thoron.boston.redhat.com (localhost.localdomain [127.0.0.1]) by thoron.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i06K5AiF008507; Tue, 6 Jan 2004 15:05:10 -0500 Received: from localhost (jmorris@localhost) by thoron.boston.redhat.com (8.12.8/8.12.8/Submit) with ESMTP id i06K5A4M008503; Tue, 6 Jan 2004 15:05:10 -0500 X-Authentication-Warning: thoron.boston.redhat.com: jmorris owned process doing -bs Date: Tue, 6 Jan 2004 15:05:10 -0500 (EST) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Harald Welte cc: netdev@oss.sgi.com, , "David S. Miller" , Stephen Smalley Subject: Re: [RFC] IPv4 Netfilter hook priorities for SELinux In-Reply-To: <20040106191311.GH934@obroa-skai.de.gnumonks.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2248 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev On Tue, 6 Jan 2004, Harald Welte wrote: > On Tue, Jan 06, 2004 at 11:01:03AM -0500, James Morris wrote: > > > Does anyone have any objections to the patch below (which I'd propose for > > 2.6.2), or other comments? > > Thanks James, I am perfectly fine with your patch. Feel free to put > them into netfilter_arp.h and netfilter_ipv6.h, too. Ok, here is the patch with support for IPv4 and IPv6. I've not added anything for ARP yet as SELinux does not have any ARP controls at this stage (and probably won't in the near future). Please apply. - James -- James Morris diff -urN -X dontdiff linux-2.6.1-rc1-mm2.pending/include/linux/netfilter_ipv4.h linux-2.6.1-rc1-mm2.w1/include/linux/netfilter_ipv4.h --- linux-2.6.1-rc1-mm2.pending/include/linux/netfilter_ipv4.h 2003-09-27 20:50:51.000000000 -0400 +++ linux-2.6.1-rc1-mm2.w1/include/linux/netfilter_ipv4.h 2004-01-06 10:14:59.000000000 -0500 @@ -51,6 +51,7 @@ enum nf_ip_hook_priorities { NF_IP_PRI_FIRST = INT_MIN, + NF_IP_PRI_SELINUX_FIRST = -225, NF_IP_PRI_CONNTRACK = -200, NF_IP_PRI_BRIDGE_SABOTAGE_FORWARD = -175, NF_IP_PRI_MANGLE = -150, @@ -58,6 +59,7 @@ NF_IP_PRI_BRIDGE_SABOTAGE_LOCAL_OUT = -50, NF_IP_PRI_FILTER = 0, NF_IP_PRI_NAT_SRC = 100, + NF_IP_PRI_SELINUX_LAST = 225, NF_IP_PRI_LAST = INT_MAX, }; diff -urN -X dontdiff linux-2.6.1-rc1-mm2.pending/include/linux/netfilter_ipv6.h linux-2.6.1-rc1-mm2.w1/include/linux/netfilter_ipv6.h --- linux-2.6.1-rc1-mm2.pending/include/linux/netfilter_ipv6.h 2003-09-27 20:50:51.000000000 -0400 +++ linux-2.6.1-rc1-mm2.w1/include/linux/netfilter_ipv6.h 2004-01-06 14:41:30.000000000 -0500 @@ -56,11 +56,13 @@ enum nf_ip6_hook_priorities { NF_IP6_PRI_FIRST = INT_MIN, + NF_IP6_PRI_SELINUX_FIRST = -225, NF_IP6_PRI_CONNTRACK = -200, NF_IP6_PRI_MANGLE = -150, NF_IP6_PRI_NAT_DST = -100, NF_IP6_PRI_FILTER = 0, NF_IP6_PRI_NAT_SRC = 100, + NF_IP6_PRI_SELINUX_LAST = 225, NF_IP6_PRI_LAST = INT_MAX, }; From dlstevens@us.ibm.com Tue Jan 6 13:45:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 13:45:19 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06LirTa027190 for ; Tue, 6 Jan 2004 13:45:00 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i06Lij6t356310; Tue, 6 Jan 2004 16:44:45 -0500 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i06Lih9J154224; Tue, 6 Jan 2004 14:44:44 -0700 Importance: Normal Sensitivity: Subject: Re: MLD problems (again) To: Takashi Hibi Cc: netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Tue, 6 Jan 2004 13:44:40 -0800 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/06/2004 14:44:44 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE480DFE791EC8f9e8a93df938690918c07BBE480DFE791EC" Content-Disposition: inline X-archive-position: 2249 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev --0__=07BBE480DFE791EC8f9e8a93df938690918c07BBE480DFE791EC Content-type: text/plain; charset=US-ASCII Takashi, I am looking at this-- I just haven't been in the office for the last two weeks. I haven't looked at it in detail, but I believe there are problems with your patch. Offhand: 1) you added a check "if (skb) skb = addgrec(skb...)" "skb == NULL" is a perfectly valid argument for addgrec(), and there aren't any circumstances I know of where you'd want to only add the record when no others had been added yet (which appears to be what this code is doing). So, this looks completely wrong to me. Either you want the record or not and it doesn't depend on whether you have other records in the report or not. 2) your patch adds a set of crcount within ip_mc_add1_src(), which if necessary would mean the other code is completely broken (which it isn't). I think this is likely either redundant or it may break other assumptions about crcount handling. There are potential races I avoided in this code, so I'm wary of why you put that in there, but I'm pretty sure it's at best unnecessary. 3) it is not correct to always automatically join a group if it's listed in a setsockopt(). I think the result of your patch to fix your problem would also automatically join groups in cases where it should return an error. General comment-- the code is set up with the assumption that an ordinary join has a filter of "EXCLUDE, empty-set". That's because the protocol makes that assumption, and reports for includes of new groups are CHANGE_TO_INCLUDE. It looks like you're trying to bypass that and set the filter directly to INCLUDE, which I expect would result in incorrect reports for some cases. Again, I have only looked at the patch context in your mail, so some of the things I think are problems probably aren't. I suspect, though, that the original cause of your problem is simply a missing "mld_ifc_event" call, though I'm not sure. Those are also carefully constructed to try to avoid multiple reports for complex transitions, when only one report will do, so some care is needed. I will look at this further and try to have an alternative patch by the end of the week. +-DLS Takashi Hibi @oss.sgi.com on 01/06/2004 04:15:42 AM Sent by: netdev-bounce@oss.sgi.com To: netdev@oss.sgi.com cc: Subject: MLD problems (again) A Happy new year. Let me discuss about the problems of MLD again. As I pointed out, there are two problems in current MLD code. 1. In MLDv1 compatibility mode, Older Version Querier Present timer expires prematurely. 2. After join SSM using setsockopt(MCAST_JOIN_SOURCE_GROUP), MLDv2 listener report isn't issued immediately. The cause of 1 is the wrong computation of timeout value. The cause of 2 is difficult to find. After tracing the code, I figured out that the mode of ifmcaddr6 isn't correctly set after setsockopt. After join by setsockopt, pmc->mca_sfmode should be MCAST_INCLUDE, but it remains MCAST_EXCLUDE. Eventually is_in() call returns false, and MLDv2 packet isn't composed. I don't know the right way to fix it, since the code is too complicated by a lot of flags. At least the following patch(diff from 2.6.0) works for me. Regards, Takashi Hibi --- mcast.c 2003-12-18 11:59:28.000000000 +0900 +++ new/mcast.c 2004-01-06 16:30:05.546174486 +0900 @@ -1050,7 +1050,7 @@ int igmp6_event_query(struct sk_buff *sk /* Translate milliseconds to jiffies */ max_delay = (ntohs(hdr->icmp6_maxdelay)*HZ)/1000; - switchback = (idev->mc_qrv + 1) * max_delay; + switchback = MLD_QRV_DEFAULT * 125*HZ + max_delay; idev->mc_v1_seen = jiffies + switchback; /* cancel the interface change timer */ @@ -1541,7 +1541,8 @@ static void mld_send_cr(struct inet6_dev type = MLD2_CHANGE_TO_EXCLUDE; else type = MLD2_CHANGE_TO_INCLUDE; - skb = add_grec(skb, pmc, type, 0, 0); + if (!skb) + skb = add_grec(skb, pmc, type, 0, 0); } spin_unlock_bh(&pmc->mca_lock); } @@ -1745,6 +1746,7 @@ static int ip6_mc_add1_src(struct ifmcad return -ENOBUFS; memset(psf, 0, sizeof(*psf)); psf->sf_addr = *psfsrc; + psf->sf_crcount = pmc->idev->mc_qrv; if (psf_prev) { psf_prev->sf_next = psf; } else @@ -1799,6 +1801,7 @@ int ip6_mc_add_src(struct inet6_dev *ide struct ifmcaddr6 *pmc; int isexclude; int i, err; + int first_join_src_grp; if (!idev) return -ENODEV; @@ -1816,6 +1819,8 @@ int ip6_mc_add_src(struct inet6_dev *ide sf_markstate(pmc); isexclude = pmc->mca_sfmode == MCAST_EXCLUDE; + first_join_src_grp = (!pmc->sources && sfmode == MCAST_INCLUDE && + sfcount == 1 && delta); if (!delta) pmc->mca_sfcount[sfmode]++; err = 0; @@ -1827,10 +1832,19 @@ int ip6_mc_add_src(struct inet6_dev *ide if (err) { int j; - pmc->mca_sfcount[sfmode]--; + if (!delta) + pmc->mca_sfcount[sfmode]--; for (j=0; jmca_sfcount[MCAST_EXCLUDE] != 0)) { + goto done; + } + if (first_join_src_grp) { + pmc->mca_sfmode = MCAST_INCLUDE; + if (sf_setstate(pmc)) + mld_ifc_event(idev); + goto done; + } + if (isexclude != (pmc->mca_sfcount[MCAST_EXCLUDE] != 0)) { struct inet6_dev *idev = pmc->idev; struct ip6_sf_list *psf; @@ -1848,6 +1862,7 @@ int ip6_mc_add_src(struct inet6_dev *ide mld_ifc_event(idev); } else if (sf_setstate(pmc)) mld_ifc_event(idev); +done: spin_unlock_bh(&pmc->mca_lock); read_unlock_bh(&idev->lock); return err; --0__=07BBE480DFE791EC8f9e8a93df938690918c07BBE480DFE791EC Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Takashi,
I am looking at this-- I just haven't been in the office for the last
two weeks. I haven't looked at it in detail, but I believe there are problems
with your patch.

Offhand:
1) you added a check "if (skb) skb = addgrec(skb...)"
"skb == NULL" is a perfectly valid argument for addgrec(), and
there aren't any circumstances I know of where you'd want to only add
the record when no others had been added yet (which appears to be
what this code is doing). So, this looks completely wrong to me. Either
you want the record or not and it doesn't depend on whether you have
other records in the report or not.

2) your patch adds a set of crcount within ip_mc_add1_src(), which if
necessary would mean the other code is completely broken (which it
isn't). I think this is likely either redundant or it may break other assumptions
about crcount handling. There are potential races I avoided in this code,
so I'm wary of why you put that in there, but I'm pretty sure it's at best
unnecessary.

3) it is not correct to always automatically join a group if it's listed in a
setsockopt(). I think the result of your patch to fix your problem would
also automatically join groups in cases where it should return an error.

General comment-- the code is set up with the assumption that an
ordinary join has a filter of "EXCLUDE, empty-set". That's because
the protocol makes that assumption, and reports for includes of new
groups are CHANGE_TO_INCLUDE. It looks like you're trying to
bypass that and set the filter directly to INCLUDE, which I expect would
result in incorrect reports for some cases.

Again, I have only looked at the patch context in your mail, so some of
the things I think are problems probably aren't. I suspect, though, that the
original cause of your problem is simply a missing "mld_ifc_event" call,
though I'm not sure. Those are also carefully constructed to try to avoid
multiple reports for complex transitions, when only one report will do, so
some care is needed. I will look at this further and try to have an alternative
patch by the end of the week.

+-DLS

Sent by: netdev-bounce@oss.sgi.com

To: netdev@oss.sgi.com
cc:
Subject: MLD problems (again)



A Happy new year.

Let me discuss about the problems of MLD again.
As I pointed out, there are two problems in current MLD code.

1. In MLDv1 compatibility mode, Older Version Querier Present timer expires
prematurely.
2. After join SSM using setsockopt(MCAST_JOIN_SOURCE_GROUP),
MLDv2 listener report isn't issued immediately.

The cause of 1 is the wrong computation of timeout value.
The cause of 2 is difficult to find. After tracing the code,
I figured out that the mode of ifmcaddr6 isn't correctly set after
setsockopt.

After join by setsockopt, pmc->mca_sfmode should be MCAST_INCLUDE,
but it remains MCAST_EXCLUDE. Eventually is_in() call returns false,
and MLDv2 packet isn't composed.
I don't know the right way to fix it, since the code is too complicated
by a lot of flags.
At least the following patch(diff from 2.6.0) works for me.

Regards,
Takashi Hibi

--- mcast.c 2003-12-18 11:59:28.000000000 +0900
+++ new/mcast.c 2004-01-06 16:30:05.546174486 +0900
@@ -1050,7 +1050,7 @@ int igmp6_event_query(struct sk_buff *sk

    /* Translate milliseconds to jiffies */
    max_delay = (ntohs(hdr->icmp6_maxdelay)*HZ)/1000;
- switchback = (idev->mc_qrv + 1) * max_delay;
+ switchback = MLD_QRV_DEFAULT * 125*HZ + max_delay;
    idev->mc_v1_seen = jiffies + switchback;
/* cancel the interface change timer */
@@ -1541,7 +1541,8 @@ static void mld_send_cr(struct inet6_dev
    type = MLD2_CHANGE_TO_EXCLUDE;
    else
type = MLD2_CHANGE_TO_INCLUDE;
- skb = add_grec(skb, pmc, type, 0, 0);
+ if (!skb)
+ skb = add_grec(skb, pmc, type, 0, 0);
    }
    spin_unlock_bh(&pmc->mca_lock);
}
@@ -1745,6 +1746,7 @@ static int ip6_mc_add1_src(struct ifmcad
    return -ENOBUFS;
    memset(psf, 0, sizeof(*psf));
    psf->sf_addr = *psfsrc;
+ psf->sf_crcount = pmc->idev->mc_qrv;
if (psf_prev) {
    psf_prev->sf_next = psf;
    } else
@@ -1799,6 +1801,7 @@ int ip6_mc_add_src(struct inet6_dev *ide
struct ifmcaddr6 *pmc;
int isexclude;
int i, err;
+ int     first_join_src_grp;
    if (!idev)
    return -ENODEV;
@@ -1816,6 +1819,8 @@ int ip6_mc_add_src(struct inet6_dev *ide
    sf_markstate(pmc);
    isexclude = pmc->mca_sfmode == MCAST_EXCLUDE;
+ first_join_src_grp = (!pmc->sources && sfmode == MCAST_INCLUDE &&
+ sfcount == 1 && delta);
    if (!delta)
    pmc->mca_sfcount[sfmode]++;
err = 0;
@@ -1827,10 +1832,19 @@ int ip6_mc_add_src(struct inet6_dev *ide
    if (err) {
    int j;
- pmc->mca_sfcount[sfmode]--;
+ if (!delta)
+ pmc->mca_sfcount[sfmode]--;
    for (j=0; j<i; j++)
    (void) ip6_mc_del1_src(pmc, sfmode, &psfsrc[i]);
- } else if (isexclude != (pmc->mca_sfcount[MCAST_EXCLUDE] != 0)) {
+ goto done;
+ }
+ if (first_join_src_grp) {
+ pmc->mca_sfmode = MCAST_INCLUDE;
+ if (sf_setstate(pmc))
+ mld_ifc_event(idev);
+ goto done;
+ }
+ if (isexclude != (pmc->mca_sfcount[MCAST_EXCLUDE] != 0)) {
    struct inet6_dev *idev = pmc->idev;
    struct ip6_sf_list *psf;
@@ -1848,6 +1862,7 @@ int ip6_mc_add_src(struct inet6_dev *ide
mld_ifc_event(idev);
    } else if (sf_setstate(pmc))
    mld_ifc_event(idev);
+done:
spin_unlock_bh(&pmc->mca_lock);
read_unlock_bh(&idev->lock);
return err;



--0__=07BBE480DFE791EC8f9e8a93df938690918c07BBE480DFE791EC-- From romieu@fr.zoreil.com Tue Jan 6 15:28:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 15:28:51 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06NSaTa032053 for ; Tue, 6 Jan 2004 15:28:37 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i06NRlsW007905; Wed, 7 Jan 2004 00:27:47 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i06NRkwp007904; Wed, 7 Jan 2004 00:27:46 +0100 Date: Wed, 7 Jan 2004 00:27:46 +0100 From: Francois Romieu To: akpm@osdl.org Cc: Jeff Garzik , netdev@oss.sgi.com, Brad House Subject: [patch] 2.6.1-rc1-mm1 - erroneous __devinitdata in the r8169 driver Message-ID: <20040107002746.A7314@electric-eye.fr.zoreil.com> References: <20031122183001.GA16993@gtf.org> <20031124000939.A456@electric-eye.fr.zoreil.com> <20031126004550.A25408@electric-eye.fr.zoreil.com> <20031127235143.A16767@electric-eye.fr.zoreil.com> <20031130014738.A2589@electric-eye.fr.zoreil.com> <3FF846C3.5070207@mainstreetsoftworks.com> <20040104233849.A3214@electric-eye.fr.zoreil.com> <20040105231741.A19514@electric-eye.fr.zoreil.com> <3FFA6981.7030006@pobox.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3FFA6981.7030006@pobox.com>; from jgarzik@pobox.com on Tue, Jan 06, 2004 at 02:53:37AM -0500 X-Organisation: Land of Sunshine Inc. X-archive-position: 2250 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, more silly bug in the r8169 driver. Brad, I would really welcome you reporting that you can send/receive a few packets (more than 64 ?) before the driver panics horribly in rtl8169_rx_interrupt. I will not be reachable from tomorrow until late friday. -- Ueimor --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="r8169-buggy-devinitdata.patch" Do not mark __devinitdata a data which is required when network device opens. drivers/net/r8169.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/r8169.c~r8169-buggy-devinitdata drivers/net/r8169.c --- linux-2.6.1-rc1-mm1/drivers/net/r8169.c~r8169-buggy-devinitdata 2004-01-07 00:01:50.000000000 +0100 +++ linux-2.6.1-rc1-mm1-romieu/drivers/net/r8169.c 2004-01-07 00:03:47.000000000 +0100 @@ -129,7 +129,7 @@ const static struct { const char *name; u8 mac_version; u32 RxConfigMask; /* Clears the bits supported by this chip */ -} rtl_chip_info[] __devinitdata = { +} rtl_chip_info[] = { _R("RTL8169", RTL_GIGA_MAC_VER_B, 0xff7e1880), _R("RTL8169s/8110s", RTL_GIGA_MAC_VER_D, 0xff7e1880), _R("RTL8169s/8110s", RTL_GIGA_MAC_VER_E, 0xff7e1880) _ --3V7upXqbjpZ4EhLz-- From hibi665@oki.com Tue Jan 6 17:52:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 17:52:32 -0800 (PST) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i071qATa005492 for ; Tue, 6 Jan 2004 17:52:11 -0800 Received: from aoi.okilab.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id KAA19104 for ; Wed, 7 Jan 2004 10:52:05 +0900 Received: (qmail 16216 invoked from network); 7 Jan 2004 10:52:04 +0900 Received: from dhcp23233.okilab.oki.co.jp (HELO kiso) (172.24.23.233) by aoi.okilab.oki.co.jp with SMTP; 7 Jan 2004 10:52:04 +0900 Message-Id: <20040107105347.52d6dc1d%hibi665@oki.com> MIME-Version: 1.0 Date: Wed, 07 Jan 2004 10:53:47 +0900 X-Mailer: Denshin 8 Go V32.1.4.3 X-My-Real-Login-Name: thibi; aoi From: Takashi Hibi To: David Stevens Cc: netdev@oss.sgi.com In-Reply-To: (Your message of "Tue, 6 Jan 2004 13:44:40 -0800") References: Subject: Re: MLD problems (again) X-archive-position: 2251 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hibi665@oki.com Precedence: bulk X-list: netdev Stevens, > > Takashi, > I am looking at this-- I just haven't been in the office for the last > two weeks. I haven't looked at it in detail, but I believe there are > problems > with your patch. > > Offhand: > 1) you added a check "if (skb) skb = addgrec(skb...)" > "skb == NULL" is a perfectly valid argument for addgrec(), and > there aren't any circumstances I know of where you'd want to only add > the record when no others had been added yet (which appears to be > what this code is doing). So, this looks completely wrong to me. Either > you want the record or not and it doesn't depend on whether you have > other records in the report or not. > OK, I missed that there may be other records. > 2) your patch adds a set of crcount within ip_mc_add1_src(), which if > necessary would mean the other code is completely broken (which it > isn't). I think this is likely either redundant or it may break other > assumptions > about crcount handling. There are potential races I avoided in this code, > so I'm wary of why you put that in there, but I'm pretty sure it's at best > unnecessary. > It may be unnecessary, I think. > 3) it is not correct to always automatically join a group if it's listed in > a > setsockopt(). I think the result of your patch to fix your problem would > also automatically join groups in cases where it should return an error. > I don't know what kind of error can be occurred. I think that error check is done in other parts. > General comment-- the code is set up with the assumption that an > ordinary join has a filter of "EXCLUDE, empty-set". That's because > the protocol makes that assumption, and reports for includes of new > groups are CHANGE_TO_INCLUDE. It looks like you're trying to > bypass that and set the filter directly to INCLUDE, which I expect would > result in incorrect reports for some cases. In some cases, both CHANGE_TO_INCLUDE and ALLOW_NEW_SOURCES can be included. It is redundant. (That is why I added the code mentioned in 1) ) When to join SSM (without previous join), is it OK to use CHANGE_TO_INCLUDE? ALLOW_NEW_SOURCES seems ordinary (and Implementation of FreeBSD is so). I couldn't judge which should be used (or both OK) from MLDv2 draft. > Again, I have only looked at the patch context in your mail, so some of > the things I think are problems probably aren't. I suspect, though, that > the > original cause of your problem is simply a missing "mld_ifc_event" call, > though I'm not sure. Those are also carefully constructed to try to avoid > multiple reports for complex transitions, when only one report will do, so > some care is needed. I will look at this further and try to have an > alternative > patch by the end of the week. No, mld_ifc_event() is called when the problem occurrs. But because of the wrong mca_sfmode value, mld_send_cr() doen't send MLD listner report. In the following code in mld_send_cr(), all add_grec() returns NULL. Regards, Takashi Hibi /* change recs */ for (pmc=idev->mc_list; pmc; pmc=pmc->next) { spin_lock_bh(&pmc->mca_lock); if (pmc->mca_sfcount[MCAST_EXCLUDE]) { type = MLD2_BLOCK_OLD_SOURCES; dtype = MLD2_ALLOW_NEW_SOURCES; } else { type = MLD2_ALLOW_NEW_SOURCES; dtype = MLD2_BLOCK_OLD_SOURCES; } skb = add_grec(skb, pmc, type, 0, 0); skb = add_grec(skb, pmc, dtype, 0, 1); /* deleted sources */ /* filter mode changes */ if (pmc->mca_crcount) { pmc->mca_crcount--; if (pmc->mca_sfmode == MCAST_EXCLUDE) type = MLD2_CHANGE_TO_EXCLUDE; else type = MLD2_CHANGE_TO_INCLUDE; skb = add_grec(skb, pmc, type, 0, 0); } spin_unlock_bh(&pmc->mca_lock); } > > +-DLS > > > Takashi Hibi @oss.sgi.com on 01/06/2004 04:15:42 AM > > Sent by: netdev-bounce@oss.sgi.com > > > To: netdev@oss.sgi.com > cc: > Subject: MLD problems (again) > > > > A Happy new year. > > Let me discuss about the problems of MLD again. > As I pointed out, there are two problems in current MLD code. > > 1. In MLDv1 compatibility mode, Older Version Querier Present timer expires > prematurely. > 2. After join SSM using setsockopt(MCAST_JOIN_SOURCE_GROUP), > MLDv2 listener report isn't issued immediately. > > The cause of 1 is the wrong computation of timeout value. > The cause of 2 is difficult to find. After tracing the code, > I figured out that the mode of ifmcaddr6 isn't correctly set after > setsockopt. > > After join by setsockopt, pmc->mca_sfmode should be MCAST_INCLUDE, > but it remains MCAST_EXCLUDE. Eventually is_in() call returns false, > and MLDv2 packet isn't composed. > I don't know the right way to fix it, since the code is too complicated > by a lot of flags. > At least the following patch(diff from 2.6.0) works for me. > > Regards, > Takashi Hibi > > --- mcast.c 2003-12-18 11:59:28.000000000 +0900 > +++ new/mcast.c 2004-01-06 16:30:05.546174486 +0900 > @@ -1050,7 +1050,7 @@ int igmp6_event_query(struct sk_buff *sk > /* Translate milliseconds to jiffies */ > max_delay = (ntohs(hdr->icmp6_maxdelay)*HZ)/1000; > > - switchback = (idev->mc_qrv + 1) * max_delay; > + switchback = MLD_QRV_DEFAULT * 125*HZ + max_delay; > idev->mc_v1_seen = jiffies + switchback; > > /* cancel the interface change timer */ > @@ -1541,7 +1541,8 @@ static void mld_send_cr(struct inet6_dev > type = MLD2_CHANGE_TO_EXCLUDE; > else > type = MLD2_CHANGE_TO_INCLUDE; > - skb = add_grec(skb, pmc, type, 0, 0); > + if (!skb) > + skb = add_grec(skb, pmc, type, 0, 0); > } > spin_unlock_bh(&pmc->mca_lock); > } > @@ -1745,6 +1746,7 @@ static int ip6_mc_add1_src(struct ifmcad > return -ENOBUFS; > memset(psf, 0, sizeof(*psf)); > psf->sf_addr = *psfsrc; > + psf->sf_crcount = pmc->idev->mc_qrv; > if (psf_prev) { > psf_prev->sf_next = psf; > } else > @@ -1799,6 +1801,7 @@ int ip6_mc_add_src(struct inet6_dev *ide > struct ifmcaddr6 *pmc; > int isexclude; > int i, err; > + int first_join_src_grp; > > if (!idev) > return -ENODEV; > @@ -1816,6 +1819,8 @@ int ip6_mc_add_src(struct inet6_dev *ide > > sf_markstate(pmc); > isexclude = pmc->mca_sfmode == MCAST_EXCLUDE; > + first_join_src_grp = (!pmc->sources && sfmode == MCAST_INCLUDE && > + sfcount == 1 && delta); > if (!delta) > pmc->mca_sfcount[sfmode]++; > err = 0; > @@ -1827,10 +1832,19 @@ int ip6_mc_add_src(struct inet6_dev *ide > if (err) { > int j; > > - pmc->mca_sfcount[sfmode]--; > + if (!delta) > + pmc->mca_sfcount[sfmode]--; > for (j=0; j (void) ip6_mc_del1_src(pmc, sfmode, &psfsrc[i]); > - } else if (isexclude != (pmc->mca_sfcount[MCAST_EXCLUDE] != 0)) { > + goto done; > + } > + if (first_join_src_grp) { > + pmc->mca_sfmode = MCAST_INCLUDE; > + if (sf_setstate(pmc)) > + mld_ifc_event(idev); > + goto done; > + } > + if (isexclude != (pmc->mca_sfcount[MCAST_EXCLUDE] != 0)) { > struct inet6_dev *idev = pmc->idev; > struct ip6_sf_list *psf; > > @@ -1848,6 +1862,7 @@ int ip6_mc_add_src(struct inet6_dev *ide > mld_ifc_event(idev); > } else if (sf_setstate(pmc)) > mld_ifc_event(idev); > +done: > spin_unlock_bh(&pmc->mca_lock); > read_unlock_bh(&idev->lock); > return err; > > From dlstevens@us.ibm.com Tue Jan 6 19:47:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 19:47:45 -0800 (PST) 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.9) with SMTP id i073lPTa006891 for ; Tue, 6 Jan 2004 19:47:31 -0800 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 i073lD19485168; Tue, 6 Jan 2004 22:47:13 -0500 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i073lD67063518; Tue, 6 Jan 2004 20:47:13 -0700 Importance: Normal Sensitivity: Subject: Re: MLD problems (again) To: Takashi Hibi Cc: netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Tue, 6 Jan 2004 19:47:09 -0800 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/06/2004 20:47:13 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE487DF81945D8f9e8a93df938690918c07BBE487DF81945D" Content-Disposition: inline X-archive-position: 2252 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev --0__=07BBE487DF81945D8f9e8a93df938690918c07BBE487DF81945D Content-type: text/plain; charset=US-ASCII >In some cases, both CHANGE_TO_INCLUDE and ALLOW_NEW_SOURCES can be included. >It is redundant. (That is why I added the code mentioned in 1) ) >When to join SSM (without previous join), is it OK to use CHANGE_TO_INCLUDE? >ALLOW_NEW_SOURCES seems ordinary (and Implementation of FreeBSD is so). >I couldn't judge which should be used (or both OK) from MLDv2 draft. We ran into something similar during testing. The problem is, I didn't have the option of rewriting all the existing multicast code. So some cases in the full-state interface that ought to be atomic are really a combination of a join and a filter mode change. The reason is because I wanted to use the existing multicast join/leave code, and leave all the existing join/leave callers alone. That can result in an extra change record, since it's indistinguishable from the two-step series of joining a group and changing the filter afterwards. But (at least with the tests we did), the report was still correct-- just not optimal. The easy solution was to write a duplicate version of mc_join_group and mc_leave_group, with some minor changes to them, for use by the source filter callers and use the nearly duplicated versions for the non-source filter callers. I chose not to do that. There is a 1-tick delay before generating the change reports and making that longer might have the desired effect, if all the non-atomic changes complete before the report is sent-- I didn't try that, but it's still not guaranteed to be atomic in the change reports. Alternatively, the source filters (if any) could've been added as an argument for the join and leave functions, which would've meant changing all of the existing calls, too. I didn't like either of those approaches, so I treated a full-state filter with auto-join as the series of join and filter change. I think the approach you're taking may mess up other cases, though, and since the report isn't incorrect, just not optimal, I planned to look at this later to see if I can think of a way around it. >No, mld_ifc_event() is called when the problem occurrs. >But because of the wrong mca_sfmode value, mld_send_cr() doen't >send MLD listner report. If the new filter has different sources, and it should, then it still should result in a change report. But again, I need to look at it in more detail before suggesting a fix. When I got your initial report, I wrote a test program and reproduced the problem, and I did some initial looking at the code but had not yet found what's going on; I'll get back to it this week. +-DLS --0__=07BBE487DF81945D8f9e8a93df938690918c07BBE487DF81945D Content-type: text/html; charset=US-ASCII Content-Disposition: inline

>In some cases, both CHANGE_TO_INCLUDE and ALLOW_NEW_SOURCES can be included.
>It is redundant. (That is why I added the code mentioned in 1) )
>When to join SSM (without previous join), is it OK to use CHANGE_TO_INCLUDE?
>ALLOW_NEW_SOURCES seems ordinary (and Implementation of FreeBSD is so).
>I couldn't judge which should be used (or both OK) from MLDv2 draft.

We ran into something similar during testing. The problem is, I didn't
have the option of rewriting all the existing multicast code. So some
cases in the full-state interface that ought to be atomic are really a
combination of a join and a filter mode change. The reason is because
I wanted to use the existing multicast join/leave code, and leave all
the existing join/leave callers alone. That can result in an
extra change record, since it's indistinguishable from the two-step series
of joining a group and changing the filter afterwards. But (at least
with the tests we did), the report was still correct-- just not optimal.

The easy solution was to write a duplicate version of mc_join_group and
mc_leave_group, with some minor changes to them, for use by the source
filter callers and use the nearly duplicated versions for the non-source
filter callers. I chose not to do that. There is a 1-tick delay before
generating the change reports and making that longer might have the
desired effect, if all the non-atomic changes complete before the report
is sent-- I didn't try that, but it's still not guaranteed to be
atomic in the change reports.

Alternatively, the source filters (if any) could've been added as an
argument for the join and leave functions, which would've meant changing
all of the existing calls, too. I didn't like either of those approaches,
so I treated a full-state filter with auto-join as the series of join and
filter change.

I think the approach you're taking may mess up other cases, though, and
since the report isn't incorrect, just not optimal, I planned to look at
this later to see if I can think of a way around it.

>No, mld_ifc_event() is called when the problem occurrs.
>But because of the wrong mca_sfmode value, mld_send_cr() doen't
>send MLD listner report.

If the new filter has different sources, and it should, then
it still should result in a change report. But again, I need to look
at it in more detail before suggesting a fix. When I got your initial
report, I wrote a test program and reproduced the problem, and I did
some initial looking at the code but had not yet found what's going
on; I'll get back to it this week.

+-DLS



--0__=07BBE487DF81945D8f9e8a93df938690918c07BBE487DF81945D-- From cmadams@hiwaay.net Tue Jan 6 20:18:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 20:19:00 -0800 (PST) Received: from mail.hiwaay.net (bee.hiwaay.net [216.180.54.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i074IlTa007605 for ; Tue, 6 Jan 2004 20:18:47 -0800 Received: from bee.hiwaay.net (localhost [127.0.0.1]) by mail.hiwaay.net (8.12.10/8.12.10) with ESMTP id i074Iku51465550 for ; Tue, 6 Jan 2004 22:18:46 -0600 (CST) Received: (from cmadams@localhost) by bee.hiwaay.net (8.12.10/8.12.10/DefSubmit) id i074Ikgh1465627 for netdev@oss.sgi.com; Tue, 6 Jan 2004 22:18:46 -0600 (CST) Date: Tue, 6 Jan 2004 22:18:46 -0600 From: Chris Adams To: netdev@oss.sgi.com Subject: Re: Problem with Compaq NC3131 dual eth card Message-ID: <20040107041845.GA1446903@hiwaay.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 2253 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cmadams@hiwaay.net Precedence: bulk X-list: netdev Once upon a time, Feldman, Scott said: > You're EEPROM image is invalid - looks like it's all 0xFFs - verify with > ethtool -e ethX. The first three words of the EEPROM should be the MAC > address. e100 errors out because it wants a valid MAC address. Yep, all 1s. > > Is my card defective or is this a compatibility problem? Is > > there a way to fix this? > > Get another nic or reprogram the EEPROM in this one. I looked at some other Intel NICs here and kind of winged it; I reprogrammed both EEPROMs, made up a couple of MACs, and it is working now. Thanks. Not bad for a $20 card picked up at a general surplus store here. It was still sealed in the box (Compaq labels on both box flaps, sealed static bag, etc.), so it must have come that way from Compaq. Maybe they had a bad batch and surplused them instead of fixing them? Now I might have to go back and pick up some more! :-) -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From davem@pizda.ninka.net Tue Jan 6 21:44:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 21:45:03 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i075ifTa011740 for ; Tue, 6 Jan 2004 21:44:41 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id VAA04099; Tue, 6 Jan 2004 21:36:42 -0800 Date: Tue, 6 Jan 2004 21:36:42 -0800 From: "David S. Miller" To: James Morris Cc: laforge@netfilter.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, sds@epoch.ncsc.mil Subject: Re: [RFC] IPv4 Netfilter hook priorities for SELinux Message-Id: <20040106213642.3b30f4bc.davem@redhat.com> In-Reply-To: References: <20040106191311.GH934@obroa-skai.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2254 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, 6 Jan 2004 15:05:10 -0500 (EST) James Morris wrote: > Ok, here is the patch with support for IPv4 and IPv6. I've not added > anything for ARP yet as SELinux does not have any ARP controls at this > stage (and probably won't in the near future). > > Please apply. Applied, thanks guys. From ak@suse.de Wed Jan 7 01:45:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 01:45:37 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i079jDTa019901 for ; Wed, 7 Jan 2004 01:45:14 -0800 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 A3A0F19A211D; Wed, 7 Jan 2004 10:07:46 +0100 (CET) Date: Wed, 7 Jan 2004 10:07:43 +0100 From: Andi Kleen To: davem@redhat.com, netdev@oss.sgi.com Subject: [PATCH] Add 32bit emulation for cmsg SO_TIMESTAMP Message-Id: <20040107100743.1c0b18c2.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (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: 2255 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 Some traceroute versions use the SO_TIMESTAMP cmsg for time measurement. This fixes them when running as 32bit on a 64bit x86-64 kernel. -Andi --- linux-2.6.1rc2-amd64/net/compat.c-o 2003-11-23 19:46:36.000000000 -0800 +++ linux-2.6.1rc2-amd64/net/compat.c 2004-01-07 00:21:43.741256711 -0800 @@ -215,15 +215,25 @@ int put_cmsg_compat(struct msghdr *kmsg, int level, int type, int len, void *data) { + struct compat_timeval ctv; struct compat_cmsghdr *cm = (struct compat_cmsghdr *) kmsg->msg_control; struct compat_cmsghdr cmhdr; - int cmlen = CMSG_COMPAT_LEN(len); + int cmlen; if(cm == NULL || kmsg->msg_controllen < sizeof(*cm)) { kmsg->msg_flags |= MSG_CTRUNC; return 0; /* XXX: return error? check spec. */ } + if (level == SOL_SOCKET && type == SO_TIMESTAMP) { + struct timeval *tv = (struct timeval *)data; + ctv.tv_sec = tv->tv_sec; + ctv.tv_usec = tv->tv_usec; + data = &ctv; + len = sizeof(struct compat_timeval); + } + + cmlen = CMSG_COMPAT_LEN(len); if(kmsg->msg_controllen < cmlen) { kmsg->msg_flags |= MSG_CTRUNC; cmlen = kmsg->msg_controllen; From vnuorval@tcs.hut.fi Wed Jan 7 01:51:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 01:51:57 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i079pXTa020436 for ; Wed, 7 Jan 2004 01:51:34 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 8DA3A8002F6; Wed, 7 Jan 2004 11:22:59 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i079Mx7Y027967; Wed, 7 Jan 2004 11:22:59 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i079Mvf4027963; Wed, 7 Jan 2004 11:22:57 +0200 Date: Wed, 7 Jan 2004 11:22:57 +0200 (EET) From: Ville Nuorvala To: davem@redhat.com Cc: yoshfuji@linux-ipv6.org, pekkas@netcore.fi, netdev@oss.sgi.com Subject: [PATCH][RESEND] IPv6: Autoconfig link-local address on ip6-ip6 tunnel device Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2256 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Hi Dave, This patch, made against cset 1.1492, adds a link-local address to a ip6-ip6 tunnel interface when it is brougth up. It also changes the router solicitation behavior slightly by checking that rtr_solicits is > 0, before sending a router solicitation after a successful DAD probe on the link-local address. 2.6.0 has been released, so would you apply this patch now? :) Thanks, Ville diff -Nru a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c --- a/net/ipv6/addrconf.c Wed Jan 7 11:07:42 2004 +++ b/net/ipv6/addrconf.c Wed Jan 7 11:07:42 2004 @@ -1809,6 +1809,54 @@ sit_route_add(dev); } +static inline int +ipv6_inherit_linklocal(struct inet6_dev *idev, struct net_device *link_dev) +{ + struct in6_addr lladdr; + + if (!ipv6_get_lladdr(link_dev, &lladdr)) { + addrconf_add_linklocal(idev, &lladdr); + return 0; + } + return -1; +} + +static void ip6_tnl_add_linklocal(struct inet6_dev *idev) +{ + struct net_device *link_dev; + + /* first try to inherit the link-local address from the link device */ + if (idev->dev->iflink && + (link_dev = __dev_get_by_index(idev->dev->iflink))) { + if (!ipv6_inherit_linklocal(idev, link_dev)) + return; + } + /* then try to inherit it from any device */ + for (link_dev = dev_base; link_dev; link_dev = link_dev->next) { + if (!ipv6_inherit_linklocal(idev, link_dev)) + return; + } + printk(KERN_DEBUG "init ip6-ip6: add_linklocal failed\n"); +} + +/* + * Autoconfigure tunnel with a link-local address so routing protocols, + * DHCPv6, MLD etc. can be run over the virtual link + */ + +static void addrconf_ip6_tnl_config(struct net_device *dev) +{ + struct inet6_dev *idev; + + ASSERT_RTNL(); + + if ((idev = addrconf_add_dev(dev)) == NULL) { + printk(KERN_DEBUG "init ip6-ip6: add_dev failed\n"); + return; + } + ip6_tnl_add_linklocal(idev); + addrconf_add_mroute(dev); +} int addrconf_notify(struct notifier_block *this, unsigned long event, void * data) @@ -1822,7 +1870,9 @@ case ARPHRD_SIT: addrconf_sit_config(dev); break; - + case ARPHRD_TUNNEL6: + addrconf_ip6_tnl_config(dev); + break; case ARPHRD_LOOPBACK: init_loopback(dev); break; @@ -2121,6 +2171,7 @@ */ if (ifp->idev->cnf.forwarding == 0 && + ifp->idev->cnf.rtr_solicits > 0 && (dev->flags&IFF_LOOPBACK) == 0 && (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) { struct in6_addr all_routers; diff -Nru a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c --- a/net/ipv6/ip6_tunnel.c Wed Jan 7 11:07:42 2004 +++ b/net/ipv6/ip6_tunnel.c Wed Jan 7 11:07:42 2004 @@ -821,6 +821,8 @@ else dev->flags &= ~IFF_POINTOPOINT; + dev->iflink = p->link; + if (p->flags & IP6_TNL_F_CAP_XMIT) { struct rt6_info *rt = rt6_lookup(&p->raddr, &p->laddr, p->link, 0); @@ -829,8 +831,6 @@ return; if (rt->rt6i_dev) { - dev->iflink = rt->rt6i_dev->ifindex; - dev->hard_header_len = rt->rt6i_dev->hard_header_len + sizeof (struct ipv6hdr); @@ -1040,7 +1040,6 @@ dev->hard_header_len = LL_MAX_HEADER + sizeof (struct ipv6hdr); dev->mtu = ETH_DATA_LEN - sizeof (struct ipv6hdr); dev->flags |= IFF_NOARP; - dev->iflink = 0; dev->addr_len = sizeof(struct in6_addr); } -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From g.liakhovetski@gmx.de Wed Jan 7 05:37:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 05:37:52 -0800 (PST) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07DbXTa001195 for ; Wed, 7 Jan 2004 05:37:33 -0800 Received: (qmail 27485 invoked by uid 65534); 7 Jan 2004 13:37:25 -0000 Received: from dialin-145-254-137-059.arcor-ip.net (EHLO poirot.grange) (145.254.137.59) by mail.gmx.net (mp004) with SMTP; 07 Jan 2004 14:37:25 +0100 X-Authenticated: #20450766 Received: from lyakh (helo=localhost) by poirot.grange with local-esmtp (Exim 3.35 #1 (Debian)) id 1AeDmR-00008g-00; Wed, 07 Jan 2004 14:31:27 +0100 Date: Wed, 7 Jan 2004 14:31:27 +0100 (CET) From: Guennadi Liakhovetski To: nfs@lists.sourceforge.net cc: netdev@oss.sgi.com, Subject: 2.6.0 NFS-server low to 0 performance (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2257 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 Sorry for cross-posting - wasn't sure which list would give the best chances. I am forwarding a problem-report, sent yesterday to lkml with a bit more data. Short: The NFS server on a PC with a 2.6.0 (release) kernel slows down to a crawl or stops completely. Searched archives - nothing fits exact enough. The server (PC1) is a 900MHz Duron with 384M RAM and a tulip 10/100 (LinkSys) network card (Linksys Network Everywhere Fast Ethernet 10/100 model NC100 (rev 17)). Clients: PC2 - Pentium 133MHz with 24M RAM and an onboard Lance 79C970 10mbps network card, a SA1100 platform (Tuxscreen / Shannon) with 16M RAM, PCMCIA Netgear 10/100mbps ne2000-compatible (pcnet_cs + 8390) card a PXA250 platform (Inphinity / Triton starter-kit) with 64M RAM, onboard SMC91C11xFD (smc91x driver) 10/100 chip In the tests below I was copying a 4M file from an NFS-mounted directory to a RAM-based fs (ramfs / tmpfs). Here are results: server with 2.6.0 kernel: PC2:2.6.0-test11 2m21s (*) PC2:2.4.20 16.5s SA1100:2.4.19-rmk7 never finishes (*) PXA:2.4.21-rmk1-pxa1 as above PXA:2.6.0-rmk1-pxa as above server: 2.4.21 PC2:2.6.0-test11 6s PC2:2.4.20 5s SA1100:2.4.19-rmk7 3.22s PXA:2.4.21-rmk1-pxa1 7s PXA:2.6.0-rmk2-pxa 1) 50s (**) (***) 2) 27s (**) (*) Messages "NFS server not responding" / "NFS server OK", "mount version older than kernel" on mount (**) Messages "NFS server not responding" / "NFS server OK", "mount version older than kernel" on mount, trafic shows as several peaks (***) 2.6.0-rmk2-pxa corresponds to the 2.6.0-rmk2 kernel with a PXA-patch forward-ported from diff-2.6.0-test2-rmk1-pxa1. The LinkSys card I bought recently, before I used a RTL (3c59x) card, only capable of 10mbps. Here are the results of today with this card: server: 2.6.0 PC2: 2.6.0-test11 9s PC2: 2.4.20 4s SA1100: 2.4.19-rmk7 never finishes server: 2.4.21 SA1100: 2.4.19-rmk7 6s Then I tried PC2 as a server with different kernels PC2: 2.6.0-test11 PC1: 2.6.0 10s SA1100: 2.4.19-rmk7 never finishes server PC2: 2.4.20 PC1: 2.6.0 6s SA1100: 2.4.19-rmk7 7s It is not just a problem of 2.6 with those specific network configurations - ftp / http / tftp transfers work fine. E.g. wget of the same file on the PXA with 2.6.0 from the PC1 with 2.4.21 over http takes about 2s. So, it is 2.6 + NFS. nfs-utils on both PC1 and PC2 version 1.0.6 (Debian Sarge). Is it fixed somewhere (2.6.1-rcx?), or what should I try / what further information is required? Sorry, I am not subscribed to any of these lists, so, please, CC. Thanks Guennadi --- Guennadi Liakhovetski From davem@pizda.ninka.net Wed Jan 7 12:18:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 12:19:11 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07KIsTa019744 for ; Wed, 7 Jan 2004 12:18:54 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA18970; Wed, 7 Jan 2004 12:12:58 -0800 Date: Wed, 7 Jan 2004 12:12:58 -0800 From: "David S. Miller" To: Andi Kleen Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Add 32bit emulation for cmsg SO_TIMESTAMP Message-Id: <20040107121258.722a7f16.davem@redhat.com> In-Reply-To: <20040107100743.1c0b18c2.ak@suse.de> References: <20040107100743.1c0b18c2.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2258 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, 7 Jan 2004 10:07:43 +0100 Andi Kleen wrote: > Some traceroute versions use the SO_TIMESTAMP cmsg for time measurement. > This fixes them when running as 32bit on a 64bit x86-64 kernel. Applied, thanks Andi. From davem@pizda.ninka.net Wed Jan 7 12:22:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 12:23:15 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07KMnTa022732 for ; Wed, 7 Jan 2004 12:22:50 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA18999; Wed, 7 Jan 2004 12:15:51 -0800 Date: Wed, 7 Jan 2004 12:15:50 -0800 From: "David S. Miller" To: Ville Nuorvala Cc: yoshfuji@linux-ipv6.org, pekkas@netcore.fi, netdev@oss.sgi.com Subject: Re: [PATCH][RESEND] IPv6: Autoconfig link-local address on ip6-ip6 tunnel device Message-Id: <20040107121550.1dba9972.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2259 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, 7 Jan 2004 11:22:57 +0200 (EET) Ville Nuorvala wrote: > This patch, made against cset 1.1492, adds a link-local address to a > ip6-ip6 tunnel interface when it is brougth up. > > It also changes the router solicitation behavior slightly by checking that > rtr_solicits is > 0, before sending a router solicitation after a > successful DAD probe on the link-local address. > > 2.6.0 has been released, so would you apply this patch now? :) Patch applied, thanks Ville. From per@hedeland.org Wed Jan 7 12:58:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 12:58:51 -0800 (PST) Received: from pluto.hedeland.org (as1-2-8.mal.s.bonet.se [194.236.4.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07KwaTa023790 for ; Wed, 7 Jan 2004 12:58:37 -0800 Received: from pluto.hedeland.org (localhost [127.0.0.1]) by pluto.hedeland.org (8.12.10/8.12.10) with ESMTP id i07KwWI5054482 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 7 Jan 2004 21:58:32 +0100 (CET) Received: (from per@localhost) by pluto.hedeland.org (8.12.10/8.12.10/Submit) id i07KwWba054481; Wed, 7 Jan 2004 21:58:32 +0100 (CET) Date: Wed, 7 Jan 2004 21:58:32 +0100 (CET) From: Per Hedeland Message-Id: <200401072058.i07KwWba054481@pluto.hedeland.org> To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] [bonding 2.4] Add balance-xor-ip bonding mode X-archive-position: 2260 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: per@hedeland.org Precedence: bulk X-list: netdev This patch adds a new bonding policy, similar to the previously existing balance-xor, but using the IP addresses rather than MAC addresses for IP packets, with fallback to MAC-based balance-xor for non-IP packets. The patch is against the netdev-2.4 tree (with Shmulik's 'update comment blocks' and Amir's 'using per-bond parameters' patches applied). --Per Hedeland per@hedeland.org diff -Nru a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt --- a/Documentation/networking/bonding.txt Wed Jan 7 16:31:56 2004 +++ b/Documentation/networking/bonding.txt Wed Jan 7 16:33:42 2004 @@ -368,6 +368,17 @@ fails it's hw address is swapped with the new curr_active_slave that was chosen. + balance-xor-ip or 7 + + XOR IP policy: Transmit based on [(source IP address + XOR'd with destination IP address) modula slave count]. + I.e. similar to balance-xor, but uses the IP addresses + rather than MAC addresses for IP packets, which provides + better load balancing in some cases (e.g. most traffic + sent to a default gateway). For non-IP packets, it will + fall back to MAC-based balance-xor. This mode provides + load balancing and fault tolerance. + primary A string (eth0, eth2, etc) to equate to a primary device. If this diff -Nru a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Wed Jan 7 16:26:59 2004 +++ b/drivers/net/bonding/bond_main.c Wed Jan 7 16:41:28 2004 @@ -476,6 +476,7 @@ #include #include #include +#include #include #include #include @@ -585,6 +586,7 @@ { "balance-rr", BOND_MODE_ROUNDROBIN}, { "active-backup", BOND_MODE_ACTIVEBACKUP}, { "balance-xor", BOND_MODE_XOR}, +{ "balance-xor-ip", BOND_MODE_XOR_IP}, { "broadcast", BOND_MODE_BROADCAST}, { "802.3ad", BOND_MODE_8023AD}, { "balance-tlb", BOND_MODE_TLB}, @@ -607,6 +609,8 @@ return "fault-tolerance (active-backup)"; case BOND_MODE_XOR : return "load balancing (xor)"; + case BOND_MODE_XOR_IP: + return "load balancing (xor-ip)"; case BOND_MODE_BROADCAST : return "fault-tolerance (broadcast)"; case BOND_MODE_8023AD: @@ -3658,16 +3662,17 @@ /* * in XOR mode, we determine the output device by performing xor on - * the source and destination hw adresses. If this device is not + * the source and destination adresses. If this device is not * enabled, find the next slave following this xor slave. */ -static int bond_xmit_xor(struct sk_buff *skb, struct net_device *bond_dev) +static int bond_xmit_xor(struct sk_buff *skb, struct net_device *bond_dev, int use_ip) { struct bonding *bond = bond_dev->priv; struct ethhdr *data = (struct ethhdr *)skb->data; struct slave *slave, *start_at; - int slave_no; + int slave_no = 0; int i; + __u32 u; read_lock(&bond->lock); @@ -3675,7 +3680,30 @@ goto free_out; } - slave_no = (data->h_dest[5]^bond_dev->dev_addr[5]) % bond->slave_cnt; + if (use_ip) { + switch (ntohs(skb->protocol)) { + case ETH_P_IP: + u = skb->nh.iph->saddr ^ skb->nh.iph->daddr; + u ^= (u >> 24) ^ (u >> 16) ^ (u >> 8); + slave_no = (u & 0xff) % bond->slave_cnt; + break; + case ETH_P_IPV6: + for (u = 0, i = 0; i < 4; i++) { + u ^= skb->nh.ipv6h->saddr.s6_addr32[i] ^ + skb->nh.ipv6h->daddr.s6_addr32[i]; + } + u ^= (u >> 24) ^ (u >> 16) ^ (u >> 8); + slave_no = (u & 0xff) % bond->slave_cnt; + break; + default: + use_ip = 0; + break; + } + } + + if (!use_ip) { + slave_no = (data->h_dest[5]^bond_dev->dev_addr[5]) % bond->slave_cnt; + } bond_for_each_slave(bond, slave, i) { slave_no--; @@ -3708,6 +3736,16 @@ goto out; } +static int bond_xmit_xor_mac(struct sk_buff *skb, struct net_device *bond_dev) +{ + return bond_xmit_xor(skb, bond_dev, 0); +} + +static int bond_xmit_xor_ip(struct sk_buff *skb, struct net_device *bond_dev) +{ + return bond_xmit_xor(skb, bond_dev, 1); +} + /* * in broadcast mode, we send everything to all usable interfaces. */ @@ -3794,7 +3832,10 @@ bond_dev->hard_start_xmit = bond_xmit_activebackup; break; case BOND_MODE_XOR: - bond_dev->hard_start_xmit = bond_xmit_xor; + bond_dev->hard_start_xmit = bond_xmit_xor_mac; + break; + case BOND_MODE_XOR_IP: + bond_dev->hard_start_xmit = bond_xmit_xor_ip; break; case BOND_MODE_BROADCAST: bond_dev->hard_start_xmit = bond_xmit_broadcast; @@ -3915,8 +3956,7 @@ for (i = 0; tbl[i].modename; i++) { if ((isdigit(*mode_arg) && tbl[i].mode == simple_strtol(mode_arg, NULL, 0)) || - (strncmp(mode_arg, tbl[i].modename, - strlen(tbl[i].modename)) == 0)) { + (strcmp(mode_arg, tbl[i].modename) == 0)) { return tbl[i].mode; } } diff -Nru a/include/linux/if_bonding.h b/include/linux/if_bonding.h --- a/include/linux/if_bonding.h Wed Jan 7 16:24:48 2004 +++ b/include/linux/if_bonding.h Wed Jan 7 16:33:42 2004 @@ -67,6 +67,7 @@ #define BOND_MODE_8023AD 4 #define BOND_MODE_TLB 5 #define BOND_MODE_ALB 6 /* TLB + RLB (receive load balancing) */ +#define BOND_MODE_XOR_IP 7 /* each slave's link has 4 states */ #define BOND_LINK_UP 0 /* link is up and running */ From per@hedeland.org Wed Jan 7 13:01:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 13:01:57 -0800 (PST) Received: from pluto.hedeland.org (as1-2-8.mal.s.bonet.se [194.236.4.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07L1hTa024229 for ; Wed, 7 Jan 2004 13:01:44 -0800 Received: from pluto.hedeland.org (localhost [127.0.0.1]) by pluto.hedeland.org (8.12.10/8.12.10) with ESMTP id i07L1cI5054665 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 7 Jan 2004 22:01:38 +0100 (CET) Received: (from per@localhost) by pluto.hedeland.org (8.12.10/8.12.10/Submit) id i07L1cOw054664; Wed, 7 Jan 2004 22:01:38 +0100 (CET) Date: Wed, 7 Jan 2004 22:01:38 +0100 (CET) From: Per Hedeland Message-Id: <200401072101.i07L1cOw054664@pluto.hedeland.org> To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] [bonding 2.6] Add balance-xor-ip bonding mode X-archive-position: 2261 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: per@hedeland.org Precedence: bulk X-list: netdev This patch adds a new bonding policy, similar to the previously existing balance-xor, but using the IP addresses rather than MAC addresses for IP packets, with fallback to MAC-based balance-xor for non-IP packets. The patch is against the net-drivers-2.5-exp tree (with Shmulik's 'update comment blocks' and Amir's 'using per-bond parameters' patches applied). --Per Hedeland per@hedeland.org diff -Nru a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt --- a/Documentation/networking/bonding.txt Wed Jan 7 16:18:11 2004 +++ b/Documentation/networking/bonding.txt Wed Jan 7 16:45:11 2004 @@ -368,6 +368,17 @@ fails it's hw address is swapped with the new curr_active_slave that was chosen. + balance-xor-ip or 7 + + XOR IP policy: Transmit based on [(source IP address + XOR'd with destination IP address) modula slave count]. + I.e. similar to balance-xor, but uses the IP addresses + rather than MAC addresses for IP packets, which provides + better load balancing in some cases (e.g. most traffic + sent to a default gateway). For non-IP packets, it will + fall back to MAC-based balance-xor. This mode provides + load balancing and fault tolerance. + primary A string (eth0, eth2, etc) to equate to a primary device. If this diff -Nru a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Wed Jan 7 16:16:19 2004 +++ b/drivers/net/bonding/bond_main.c Wed Jan 7 16:45:11 2004 @@ -476,6 +476,7 @@ #include #include #include +#include #include #include #include @@ -585,6 +586,7 @@ { "balance-rr", BOND_MODE_ROUNDROBIN}, { "active-backup", BOND_MODE_ACTIVEBACKUP}, { "balance-xor", BOND_MODE_XOR}, +{ "balance-xor-ip", BOND_MODE_XOR_IP}, { "broadcast", BOND_MODE_BROADCAST}, { "802.3ad", BOND_MODE_8023AD}, { "balance-tlb", BOND_MODE_TLB}, @@ -607,6 +609,8 @@ return "fault-tolerance (active-backup)"; case BOND_MODE_XOR : return "load balancing (xor)"; + case BOND_MODE_XOR_IP: + return "load balancing (xor-ip)"; case BOND_MODE_BROADCAST : return "fault-tolerance (broadcast)"; case BOND_MODE_8023AD: @@ -3657,16 +3661,17 @@ /* * in XOR mode, we determine the output device by performing xor on - * the source and destination hw adresses. If this device is not + * the source and destination adresses. If this device is not * enabled, find the next slave following this xor slave. */ -static int bond_xmit_xor(struct sk_buff *skb, struct net_device *bond_dev) +static int bond_xmit_xor(struct sk_buff *skb, struct net_device *bond_dev, int use_ip) { struct bonding *bond = bond_dev->priv; struct ethhdr *data = (struct ethhdr *)skb->data; struct slave *slave, *start_at; - int slave_no; + int slave_no = 0; int i; + __u32 u; read_lock(&bond->lock); @@ -3674,7 +3679,30 @@ goto free_out; } - slave_no = (data->h_dest[5]^bond_dev->dev_addr[5]) % bond->slave_cnt; + if (use_ip) { + switch (ntohs(skb->protocol)) { + case ETH_P_IP: + u = skb->nh.iph->saddr ^ skb->nh.iph->daddr; + u ^= (u >> 24) ^ (u >> 16) ^ (u >> 8); + slave_no = (u & 0xff) % bond->slave_cnt; + break; + case ETH_P_IPV6: + for (u = 0, i = 0; i < 4; i++) { + u ^= skb->nh.ipv6h->saddr.s6_addr32[i] ^ + skb->nh.ipv6h->daddr.s6_addr32[i]; + } + u ^= (u >> 24) ^ (u >> 16) ^ (u >> 8); + slave_no = (u & 0xff) % bond->slave_cnt; + break; + default: + use_ip = 0; + break; + } + } + + if (!use_ip) { + slave_no = (data->h_dest[5]^bond_dev->dev_addr[5]) % bond->slave_cnt; + } bond_for_each_slave(bond, slave, i) { slave_no--; @@ -3707,6 +3735,16 @@ goto out; } +static int bond_xmit_xor_mac(struct sk_buff *skb, struct net_device *bond_dev) +{ + return bond_xmit_xor(skb, bond_dev, 0); +} + +static int bond_xmit_xor_ip(struct sk_buff *skb, struct net_device *bond_dev) +{ + return bond_xmit_xor(skb, bond_dev, 1); +} + /* * in broadcast mode, we send everything to all usable interfaces. */ @@ -3793,7 +3831,10 @@ bond_dev->hard_start_xmit = bond_xmit_activebackup; break; case BOND_MODE_XOR: - bond_dev->hard_start_xmit = bond_xmit_xor; + bond_dev->hard_start_xmit = bond_xmit_xor_mac; + break; + case BOND_MODE_XOR_IP: + bond_dev->hard_start_xmit = bond_xmit_xor_ip; break; case BOND_MODE_BROADCAST: bond_dev->hard_start_xmit = bond_xmit_broadcast; @@ -3914,8 +3955,7 @@ for (i = 0; tbl[i].modename; i++) { if ((isdigit(*mode_arg) && tbl[i].mode == simple_strtol(mode_arg, NULL, 0)) || - (strncmp(mode_arg, tbl[i].modename, - strlen(tbl[i].modename)) == 0)) { + (strcmp(mode_arg, tbl[i].modename) == 0)) { return tbl[i].mode; } } diff -Nru a/include/linux/if_bonding.h b/include/linux/if_bonding.h --- a/include/linux/if_bonding.h Wed Jan 7 16:21:37 2004 +++ b/include/linux/if_bonding.h Wed Jan 7 16:45:11 2004 @@ -67,6 +67,7 @@ #define BOND_MODE_8023AD 4 #define BOND_MODE_TLB 5 #define BOND_MODE_ALB 6 /* TLB + RLB (receive load balancing) */ +#define BOND_MODE_XOR_IP 7 /* each slave's link has 4 states */ #define BOND_LINK_UP 0 /* link is up and running */ From willy@w.ods.org Wed Jan 7 13:03:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 13:03:20 -0800 (PST) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07L35Ta024586 for ; Wed, 7 Jan 2004 13:03:06 -0800 Date: Wed, 7 Jan 2004 22:02:55 +0100 From: Willy Tarreau To: Stephan von Krawczynski Cc: linux-kernel , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Problem with 2.4.24 e1000 and keepalived Message-ID: <20040107210255.GA545@alpha.home.local> References: <20040107200556.0d553c40.skraw@ithnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040107200556.0d553c40.skraw@ithnet.com> User-Agent: Mutt/1.4i X-archive-position: 2262 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 Stephan, On Wed, Jan 07, 2004 at 08:05:56PM +0100, Stephan von Krawczynski wrote: > Setup is a simple pair of routers with 2 nics each, all e1000. If you start a > vrrp setup with keepalived and interface state is down during keepalived > startup, then the failover does not work. If the nics are UP during startup > everything works well. Now the kernel part of the story: the exact same setup > works with tulip cards. > Is there a difference regarding UP/DOWN state handling/events in e1000 and > tulip. e100 and eepro100 show the same problem btw. I noticed the exact same problem about 1 year ago with the early 2.4 bonding code and eepro100. At this time, I attributed this to a yet undiscovered but in the bonding state machine, and could not investigate much since it was on a remote production machine. Someone went there and rebooted it and everything went OK. Before the reboot, the switch alredy detected an UP link, while the bonding code saw it down (using MII at this time, not ethtool). I recently read one report (here or on keepalived list) about someone who got the same problem with another eepro100. I wonder whether there would not be a bug either in the driver or in the chip itself. What I noticed is that if you load the driver while the cable is unplugged, and then plug it, the MII status says the link is still down. Unfortunately, the only e100 I have access to are in prod at a customer's and I really cannot make tests there. Cheers, Willy From greearb@candelatech.com Wed Jan 7 18:45:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 18:45:28 -0800 (PST) Received: from ns1.wanfear.com (ns1.wanfear.com [207.212.57.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i082jFTa004198 for ; Wed, 7 Jan 2004 18:45:15 -0800 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by ns1.wanfear.com (8.12.10/8.12.8) with ESMTP id i082j5Eu021315; Wed, 7 Jan 2004 18:45:07 -0800 Message-ID: <3FFCC430.4060804@candelatech.com> Date: Wed, 07 Jan 2004 18:45:04 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Willy Tarreau CC: Stephan von Krawczynski , linux-kernel , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Problem with 2.4.24 e1000 and keepalived References: <20040107200556.0d553c40.skraw@ithnet.com> <20040107210255.GA545@alpha.home.local> In-Reply-To: <20040107210255.GA545@alpha.home.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2264 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 Content-Length: 2044 Lines: 53 Willy Tarreau wrote: > Hi Stephan, > > On Wed, Jan 07, 2004 at 08:05:56PM +0100, Stephan von Krawczynski wrote: > >>Setup is a simple pair of routers with 2 nics each, all e1000. If you start a >>vrrp setup with keepalived and interface state is down during keepalived >>startup, then the failover does not work. If the nics are UP during startup >>everything works well. Now the kernel part of the story: the exact same setup >>works with tulip cards. >>Is there a difference regarding UP/DOWN state handling/events in e1000 and >>tulip. e100 and eepro100 show the same problem btw. > > > I noticed the exact same problem about 1 year ago with the early 2.4 > bonding code and eepro100. At this time, I attributed this to a yet > undiscovered but in the bonding state machine, and could not investigate > much since it was on a remote production machine. Someone went there and > rebooted it and everything went OK. Before the reboot, the switch alredy > detected an UP link, while the bonding code saw it down (using MII at this > time, not ethtool). I recently read one report (here or on keepalived list) > about someone who got the same problem with another eepro100. I wonder > whether there would not be a bug either in the driver or in the chip itself. > > What I noticed is that if you load the driver while the cable is unplugged, > and then plug it, the MII status says the link is still down. Unfortunately, > the only e100 I have access to are in prod at a customer's and I really > cannot make tests there. You have to bring the interface 'UP' before it will detect link, with something like: ifconfig eth2 up Could that be the problem? Ben > > Cheers, > Willy > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From willy@w.ods.org Wed Jan 7 21:20:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 21:20:38 -0800 (PST) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i085KGTa010187 for ; Wed, 7 Jan 2004 21:20:17 -0800 Date: Thu, 8 Jan 2004 06:20:00 +0100 From: Willy Tarreau To: Ben Greear Cc: Willy Tarreau , Stephan von Krawczynski , linux-kernel , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Problem with 2.4.24 e1000 and keepalived Message-ID: <20040108052000.GA8829@alpha.home.local> References: <20040107200556.0d553c40.skraw@ithnet.com> <20040107210255.GA545@alpha.home.local> <3FFCC430.4060804@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FFCC430.4060804@candelatech.com> User-Agent: Mutt/1.4i X-archive-position: 2265 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 Content-Length: 561 Lines: 16 Hi Ben, On Wed, Jan 07, 2004 at 06:45:04PM -0800, Ben Greear wrote: > You have to bring the interface 'UP' before it will detect link, > with something like: ifconfig eth2 up Don't you mean "after" instead of "before" here ? Because the case where it doesn't work is when everything is set up while the cable is unplugged, but conversely, if the system goes up with the cable plugged, setting the interface UP detects the link as UP and works. I believe that the problem is related to setting the interface UP with nothing plugged into it. Cheers, Willy From andi@muc.de Wed Jan 7 23:04:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 23:04:35 -0800 (PST) Received: from averell.firstfloor.org (personne@pD9E56430.dip.t-dialin.net [217.229.100.48]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0874JTa011645 for ; Wed, 7 Jan 2004 23:04:20 -0800 Received: from averell.firstfloor.org (localhost [127.0.0.1]) by averell.firstfloor.org (8.12.6/8.12.6/SuSE Linux 0.6) with ESMTP id i0874EBQ031786; Thu, 8 Jan 2004 08:04:14 +0100 Received: (from andi@localhost) by averell.firstfloor.org (8.12.6/8.12.6/Submit) id i0874D0c031785; Thu, 8 Jan 2004 08:04:13 +0100 Date: Thu, 8 Jan 2004 08:04:13 +0100 From: Andi Kleen To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH] Mark SIOCSIFNAME as compatible ioctl Message-ID: <20040108070413.GA31778@averell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 2266 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: 678 Lines: 18 Mark SIOCSIFNAME as an ioctl that doesn't need 32bit conversion. Fixes nameif as 32bit executable. -Andi diff -X ../KDIFX -burpN linux-vanilla-2.6.1rc2/include/linux/compat_ioctl.h linux-2.6.1rc2-amd64/include/linux/compat_ioctl.h --- linux-vanilla-2.6.1rc2/include/linux/compat_ioctl.h 2004-01-07 02:36:31.000000000 -0800 +++ linux-2.6.1rc2-amd64/include/linux/compat_ioctl.h 2003-12-31 21:56:55.000000000 -0800 @@ -260,6 +260,7 @@ COMPATIBLE_IOCTL(SIOCATMARK) COMPATIBLE_IOCTL(SIOCSIFLINK) COMPATIBLE_IOCTL(SIOCSIFENCAP) COMPATIBLE_IOCTL(SIOCGIFENCAP) +COMPATIBLE_IOCTL(SIOCSIFNAME) COMPATIBLE_IOCTL(SIOCSIFBR) COMPATIBLE_IOCTL(SIOCGIFBR) COMPATIBLE_IOCTL(SIOCSARP) From greearb@candelatech.com Thu Jan 8 00:07:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 00:07:40 -0800 (PST) Received: from ns1.wanfear.com (ns1.wanfear.com [207.212.57.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0887HTa012814 for ; Thu, 8 Jan 2004 00:07:17 -0800 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by ns1.wanfear.com (8.12.10/8.12.8) with ESMTP id i0887BEu030492; Thu, 8 Jan 2004 00:07:11 -0800 Message-ID: <3FFD0FAE.8050705@candelatech.com> Date: Thu, 08 Jan 2004 00:07:10 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Willy Tarreau CC: Stephan von Krawczynski , linux-kernel , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Problem with 2.4.24 e1000 and keepalived References: <20040107200556.0d553c40.skraw@ithnet.com> <20040107210255.GA545@alpha.home.local> <3FFCC430.4060804@candelatech.com> <20040108052000.GA8829@alpha.home.local> In-Reply-To: <20040108052000.GA8829@alpha.home.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2267 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 Content-Length: 1150 Lines: 38 Willy Tarreau wrote: > Hi Ben, > > On Wed, Jan 07, 2004 at 06:45:04PM -0800, Ben Greear wrote: > > >>You have to bring the interface 'UP' before it will detect link, >>with something like: ifconfig eth2 up > > > Don't you mean "after" instead of "before" here ? Because the case where > it doesn't work is when everything is set up while the cable is unplugged, > but conversely, if the system goes up with the cable plugged, setting the > interface UP detects the link as UP and works. I believe that the problem > is related to setting the interface UP with nothing plugged into it. No, I meant what I said: You have to tell many drivers to bring the interface up before they will attempt (or at least report) link negotiation. You do NOT have to give it an IP address or add any routes to it. But, I don't know about your particular program, I just suspect it is related to detecting link state. I think tg3 detects link when the interface is not UP, if you have some tg3 nics maybe you could try with them? Ben > > Cheers, > Willy > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From skraw@ithnet.com Thu Jan 8 00:15:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 00:15:16 -0800 (PST) Received: from ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i088F2Ta013257 for ; Thu, 8 Jan 2004 00:15:03 -0800 Received: (qmail 10514 invoked by uid 0); 8 Jan 2004 08:14:41 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.65375 secs); 08 Jan 2004 08:14:41 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 8 Jan 2004 08:14:40 -0000 X-Sender-Authentication: net64 Date: Thu, 8 Jan 2004 09:14:41 +0100 From: Stephan von Krawczynski To: Ben Greear Cc: willy@w.ods.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Problem with 2.4.24 e1000 and keepalived Message-Id: <20040108091441.3ff81b53.skraw@ithnet.com> In-Reply-To: <3FFCC430.4060804@candelatech.com> References: <20040107200556.0d553c40.skraw@ithnet.com> <20040107210255.GA545@alpha.home.local> <3FFCC430.4060804@candelatech.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.8 (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: 2268 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev Content-Length: 1020 Lines: 42 On Wed, 07 Jan 2004 18:45:04 -0800 Ben Greear wrote: > Willy Tarreau wrote: > > Hi Stephan, > > [...] > > What I noticed is that if you load the driver while the cable is unplugged, > > and then plug it, the MII status says the link is still down. > > Unfortunately, the only e100 I have access to are in prod at a customer's > > and I really cannot make tests there. > > You have to bring the interface 'UP' before it will detect link, > with something like: ifconfig eth2 up > > Could that be the problem? > > Ben Hi Ben, the situation is like this (exactly this works flawlessly with tulip): - unplug all interfaces from the switches - reboot box - plug in _one_ interface - log into the box (yes, network works flawlessly) - start keepalived - now plug in rest of the interfaces - watch keepalived do _nothing_ (seems no UP event shows up) in comparison to: - let all interfaces plugged in - reboot box - log in - start keepalived - watch it work as expected Regards, Stephan From willy@w.ods.org Thu Jan 8 00:46:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 00:46:35 -0800 (PST) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i088kITa016724 for ; Thu, 8 Jan 2004 00:46:19 -0800 Date: Thu, 8 Jan 2004 09:46:05 +0100 From: Willy Tarreau To: Ben Greear Cc: Willy Tarreau , Stephan von Krawczynski , linux-kernel , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Problem with 2.4.24 e1000 and keepalived Message-ID: <20040108084605.GA9050@alpha.home.local> References: <20040107200556.0d553c40.skraw@ithnet.com> <20040107210255.GA545@alpha.home.local> <3FFCC430.4060804@candelatech.com> <20040108052000.GA8829@alpha.home.local> <3FFD0FAE.8050705@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FFD0FAE.8050705@candelatech.com> User-Agent: Mutt/1.4i X-archive-position: 2269 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 Content-Length: 741 Lines: 20 On Thu, Jan 08, 2004 at 12:07:10AM -0800, Ben Greear wrote: > No, I meant what I said: You have to tell many drivers to bring the > interface > up before they will attempt (or at least report) link negotiation. > You do NOT have to give it an IP address or add any routes to it. ah, OK. No, anyway, it is just a matter of wrongly detecting link state after the link has been plugged while the interface was already UP, no matter if an IP was set or not. > But, I don't know about your particular program, I just suspect it > is related to detecting link state. I think tg3 detects link when > the interface is not UP, if you have some tg3 nics maybe you could > try with them? As far as I have tested, tg3 are fine WRT this. Willy From willy@w.ods.org Thu Jan 8 00:48:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 00:48:22 -0800 (PST) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i088m7Ta017074 for ; Thu, 8 Jan 2004 00:48:08 -0800 Date: Thu, 8 Jan 2004 09:47:58 +0100 From: Willy Tarreau To: Stephan von Krawczynski Cc: Ben Greear , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Problem with 2.4.24 e1000 and keepalived Message-ID: <20040108084758.GB9050@alpha.home.local> References: <20040107200556.0d553c40.skraw@ithnet.com> <20040107210255.GA545@alpha.home.local> <3FFCC430.4060804@candelatech.com> <20040108091441.3ff81b53.skraw@ithnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040108091441.3ff81b53.skraw@ithnet.com> User-Agent: Mutt/1.4i X-archive-position: 2270 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 Content-Length: 520 Lines: 16 On Thu, Jan 08, 2004 at 09:14:41AM +0100, Stephan von Krawczynski wrote: > the situation is like this (exactly this works flawlessly with tulip): > > - unplug all interfaces from the switches > - reboot box > - plug in _one_ interface > - log into the box (yes, network works flawlessly) > - start keepalived > - now plug in rest of the interfaces > - watch keepalived do _nothing_ (seems no UP event shows up) I agree with this description, and would add : - mii-diag ethX or ethtool ethX report link down Willy From amir.noam@intel.com Thu Jan 8 07:34:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 07:34:33 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08FYFTa005086 for ; Thu, 8 Jan 2004 07:34:17 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08FXoek007175; Thu, 8 Jan 2004 15:33:50 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08FXoxV029495; Thu, 8 Jan 2004 15:33:50 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010817334918087 ; Thu, 08 Jan 2004 17:33:49 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08FXihb002518; Thu, 8 Jan 2004 17:33:46 +0200 (IST) From: Amir Noam To: "Per Hedeland" Subject: Re: [Bonding-devel] [PATCH] [bonding 2.4] Add balance-xor-ip bonding mode Date: Thu, 8 Jan 2004 17:33:44 +0200 User-Agent: KMail/1.5.3 References: In-Reply-To: Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081733.44744.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2271 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 1113 Lines: 39 On Wednesday 07 January 2004 10:58 pm, Per Hedeland wrote: > struct bonding *bond = bond_dev->priv; > struct ethhdr *data = (struct ethhdr *)skb->data; > struct slave *slave, *start_at; > - int slave_no; > + int slave_no = 0; > int i; > + __u32 u; > > read_lock(&bond->lock); > Please use u32 instead of __u32. > +static int bond_xmit_xor_mac(struct sk_buff *skb, struct net_device *bond_dev) > +{ > + return bond_xmit_xor(skb, bond_dev, 0); > +} > + > +static int bond_xmit_xor_ip(struct sk_buff *skb, struct net_device *bond_dev) > +{ > + return bond_xmit_xor(skb, bond_dev, 1); > +} > + hmm... I don't like this. The reason we give different tx function pointers to dev->hard_start_xmit in different bonding mode is to make the tx path as fast as possible. Otherwise we might as well use a single tx function that chooses its exact operation based on the bonding mode. It might be better to have some code duplication if it results in faster tx, but I'm not sure what's the optimal solution in this case. -- Amir From tony.cureington@hp.com Thu Jan 8 07:36:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 07:37:07 -0800 (PST) Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08FasTa005369 for ; Thu, 8 Jan 2004 07:36:54 -0800 Received: from cacexg12.americas.cpqcorp.net (cacexg12.americas.cpqcorp.net [16.92.1.46]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id B53D3B9D0; Thu, 8 Jan 2004 07:36:48 -0800 (PST) Received: from txnexc01.americas.cpqcorp.net ([16.74.7.21]) by cacexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Jan 2004 07:36:46 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Bonding-devel] [PATCH] [bonding 2.6] Add balance-xor-ip bonding mode Date: Thu, 8 Jan 2004 09:36:44 -0600 Message-ID: <72A87F7160C0994D8C5A36E2FDC227F502B3E9BE@txnexc01.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Bonding-devel] [PATCH] [bonding 2.6] Add balance-xor-ip bonding mode Thread-Index: AcPVYdqSPbokhakcSIif9UDWkwRTywAG92qw From: "Cureington, Tony" To: "Per Hedeland" , , X-OriginalArrivalTime: 08 Jan 2004 15:36:46.0253 (UTC) FILETIME=[395FD5D0:01C3D5FD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i08FasTa005369 X-archive-position: 2272 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tony.cureington@hp.com Precedence: bulk X-list: netdev Content-Length: 6717 Lines: 204 I'm curious of the reasoning behind "u ^= (u >> 24) ^ (u >> 16) ^ (u >> 8);", what advantages does it have over using the xor'd addresses just before this line? Maybe someone loaded decaf on me this morning? :-/ Thanks! > -----Original Message----- > From: bonding-devel-admin@lists.sourceforge.net > [mailto:bonding-devel-admin@lists.sourceforge.net]On Behalf Of Per > Hedeland > Sent: Wednesday, January 07, 2004 3:02 PM > To: bonding-devel@lists.sourceforge.net; netdev@oss.sgi.com > Subject: [Bonding-devel] [PATCH] [bonding 2.6] Add balance-xor-ip > bonding mode > > > This patch adds a new bonding policy, similar to the > previously existing > balance-xor, but using the IP addresses rather than MAC > addresses for IP > packets, with fallback to MAC-based balance-xor for non-IP packets. > > The patch is against the net-drivers-2.5-exp tree (with Shmulik's > 'update comment blocks' and Amir's 'using per-bond parameters' patches > applied). > > --Per Hedeland > per@hedeland.org > > > diff -Nru a/Documentation/networking/bonding.txt > b/Documentation/networking/bonding.txt > --- a/Documentation/networking/bonding.txt Wed Jan 7 16:18:11 2004 > +++ b/Documentation/networking/bonding.txt Wed Jan 7 16:45:11 2004 > @@ -368,6 +368,17 @@ > fails it's hw address is swapped with the new > curr_active_slave > that was chosen. > > + balance-xor-ip or 7 > + > + XOR IP policy: Transmit based on [(source IP address > + XOR'd with destination IP address) modula slave count]. > + I.e. similar to balance-xor, but uses the IP addresses > + rather than MAC addresses for IP packets, which provides > + better load balancing in some cases (e.g. most traffic > + sent to a default gateway). For non-IP packets, it will > + fall back to MAC-based balance-xor. This mode provides > + load balancing and fault tolerance. > + > primary > > A string (eth0, eth2, etc) to equate to a primary > device. If this > diff -Nru a/drivers/net/bonding/bond_main.c > b/drivers/net/bonding/bond_main.c > --- a/drivers/net/bonding/bond_main.c Wed Jan 7 16:16:19 2004 > +++ b/drivers/net/bonding/bond_main.c Wed Jan 7 16:45:11 2004 > @@ -476,6 +476,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -585,6 +586,7 @@ > { "balance-rr", BOND_MODE_ROUNDROBIN}, > { "active-backup", BOND_MODE_ACTIVEBACKUP}, > { "balance-xor", BOND_MODE_XOR}, > +{ "balance-xor-ip", BOND_MODE_XOR_IP}, > { "broadcast", BOND_MODE_BROADCAST}, > { "802.3ad", BOND_MODE_8023AD}, > { "balance-tlb", BOND_MODE_TLB}, > @@ -607,6 +609,8 @@ > return "fault-tolerance (active-backup)"; > case BOND_MODE_XOR : > return "load balancing (xor)"; > + case BOND_MODE_XOR_IP: > + return "load balancing (xor-ip)"; > case BOND_MODE_BROADCAST : > return "fault-tolerance (broadcast)"; > case BOND_MODE_8023AD: > @@ -3657,16 +3661,17 @@ > > /* > * in XOR mode, we determine the output device by performing xor on > - * the source and destination hw adresses. If this device is not > + * the source and destination adresses. If this device is not > * enabled, find the next slave following this xor slave. > */ > -static int bond_xmit_xor(struct sk_buff *skb, struct > net_device *bond_dev) > +static int bond_xmit_xor(struct sk_buff *skb, struct > net_device *bond_dev, int use_ip) > { > struct bonding *bond = bond_dev->priv; > struct ethhdr *data = (struct ethhdr *)skb->data; > struct slave *slave, *start_at; > - int slave_no; > + int slave_no = 0; > int i; > + __u32 u; > > read_lock(&bond->lock); > > @@ -3674,7 +3679,30 @@ > goto free_out; > } > > - slave_no = (data->h_dest[5]^bond_dev->dev_addr[5]) % > bond->slave_cnt; > + if (use_ip) { > + switch (ntohs(skb->protocol)) { > + case ETH_P_IP: > + u = skb->nh.iph->saddr ^ skb->nh.iph->daddr; > + u ^= (u >> 24) ^ (u >> 16) ^ (u >> 8); > + slave_no = (u & 0xff) % bond->slave_cnt; > + break; > + case ETH_P_IPV6: > + for (u = 0, i = 0; i < 4; i++) { > + u ^= skb->nh.ipv6h->saddr.s6_addr32[i] ^ > + > skb->nh.ipv6h->daddr.s6_addr32[i]; > + } > + u ^= (u >> 24) ^ (u >> 16) ^ (u >> 8); > + slave_no = (u & 0xff) % bond->slave_cnt; > + break; > + default: > + use_ip = 0; > + break; > + } > + } > + > + if (!use_ip) { > + slave_no = > (data->h_dest[5]^bond_dev->dev_addr[5]) % bond->slave_cnt; > + } > > bond_for_each_slave(bond, slave, i) { > slave_no--; > @@ -3707,6 +3735,16 @@ > goto out; > } > > +static int bond_xmit_xor_mac(struct sk_buff *skb, struct > net_device *bond_dev) > +{ > + return bond_xmit_xor(skb, bond_dev, 0); > +} > + > +static int bond_xmit_xor_ip(struct sk_buff *skb, struct > net_device *bond_dev) > +{ > + return bond_xmit_xor(skb, bond_dev, 1); > +} > + > /* > * in broadcast mode, we send everything to all usable interfaces. > */ > @@ -3793,7 +3831,10 @@ > bond_dev->hard_start_xmit = bond_xmit_activebackup; > break; > case BOND_MODE_XOR: > - bond_dev->hard_start_xmit = bond_xmit_xor; > + bond_dev->hard_start_xmit = bond_xmit_xor_mac; > + break; > + case BOND_MODE_XOR_IP: > + bond_dev->hard_start_xmit = bond_xmit_xor_ip; > break; > case BOND_MODE_BROADCAST: > bond_dev->hard_start_xmit = bond_xmit_broadcast; > @@ -3914,8 +3955,7 @@ > for (i = 0; tbl[i].modename; i++) { > if ((isdigit(*mode_arg) && > tbl[i].mode == simple_strtol(mode_arg, NULL, 0)) || > - (strncmp(mode_arg, tbl[i].modename, > - strlen(tbl[i].modename)) == 0)) { > + (strcmp(mode_arg, tbl[i].modename) == 0)) { > return tbl[i].mode; > } > } > diff -Nru a/include/linux/if_bonding.h b/include/linux/if_bonding.h > --- a/include/linux/if_bonding.h Wed Jan 7 16:21:37 2004 > +++ b/include/linux/if_bonding.h Wed Jan 7 16:45:11 2004 > @@ -67,6 +67,7 @@ > #define BOND_MODE_8023AD 4 > #define BOND_MODE_TLB 5 > #define BOND_MODE_ALB 6 /* TLB + RLB (receive > load balancing) */ > +#define BOND_MODE_XOR_IP 7 > > /* each slave's link has 4 states */ > #define BOND_LINK_UP 0 /* link is up and running */ > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Bonding-devel mailing list > Bonding-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bonding-devel > From amir.noam@intel.com Thu Jan 8 08:20:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:20:57 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GKcTa010497 for ; Thu, 8 Jan 2004 08:20:40 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08GJxek011628; Thu, 8 Jan 2004 16:19:59 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08GJqxZ000523; Thu, 8 Jan 2004 16:19:59 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010818195818982 ; Thu, 08 Jan 2004 18:19:58 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08GJshb003823; Thu, 8 Jan 2004 18:19:55 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [bonding] Add basic support for dynamic configuration of bond interfaces Date: Thu, 8 Jan 2004 18:19:54 +0200 User-Agent: KMail/1.5.3 Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081819.54484.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2273 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 471 Lines: 15 The following patch sets provide basic support for future bonding operations (specifically for dynamic configuration of bonding interfaces). This is done by adding two new bonding ioctls: one for deviceless commands (an ioctl hook) and one for device oriented commands. Like ethtool, the first u32 value in the data structure will indicate the exact sub-command to be executed. The sets are against the latest netdev-2.4 and net-drivers-2.5-exp trees. -- Amir From amir.noam@intel.com Thu Jan 8 08:21:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:21:57 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GLeTa010554 for ; Thu, 8 Jan 2004 08:21:43 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08GLQek011940; Thu, 8 Jan 2004 16:21:26 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08GLJxX000750; Thu, 8 Jan 2004 16:21:25 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010818212519064 ; Thu, 08 Jan 2004 18:21:25 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08GLOhb003850; Thu, 8 Jan 2004 18:21:25 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 1/4] [bonding 2.4] Add bonding ioctl hook Date: Thu, 8 Jan 2004 18:21:23 +0200 User-Agent: KMail/1.5.3 Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081821.24881.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2274 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 3218 Lines: 102 Add two bonding ioctls: SIOCBONDING: ioctl hook to handle commands not directed at a specific bond interface. SIOCBONDDEVICE: ioctl to handle commands for a bond interface. This ioctl can also handle all existing commands, so we can regard them as obsolete in the future. All future bonding operations will be a sub-command of one of these ioctls. diff -Nuarp a/include/linux/sockios.h b/include/linux/sockios.h --- a/include/linux/sockios.h Tue Jan 6 20:40:06 2004 +++ b/include/linux/sockios.h Tue Jan 6 20:40:08 2004 @@ -115,7 +115,9 @@ #define SIOCBONDSLAVEINFOQUERY 0x8993 /* rtn info about slave state */ #define SIOCBONDINFOQUERY 0x8994 /* rtn info about bond state */ #define SIOCBONDCHANGEACTIVE 0x8995 /* update to a new active slave */ - +#define SIOCBONDING 0x8996 /* deviceless bonding commands */ +#define SIOCBONDDEVICE 0x8997 /* device oriented bonding commands */ + /* Device private ioctl calls */ /* diff -Nuarp a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Tue Jan 6 20:40:06 2004 +++ b/net/core/dev.c Tue Jan 6 20:40:08 2004 @@ -2199,6 +2199,7 @@ static int dev_ifsioc(struct ifreq *ifr, cmd == SIOCBONDSLAVEINFOQUERY || cmd == SIOCBONDINFOQUERY || cmd == SIOCBONDCHANGEACTIVE || + cmd == SIOCBONDDEVICE || cmd == SIOCGMIIPHY || cmd == SIOCGMIIREG || cmd == SIOCSMIIREG || @@ -2358,6 +2359,7 @@ int dev_ioctl(unsigned int cmd, void *ar case SIOCBONDSLAVEINFOQUERY: case SIOCBONDINFOQUERY: case SIOCBONDCHANGEACTIVE: + case SIOCBONDDEVICE: if (!capable(CAP_NET_ADMIN)) return -EPERM; dev_load(ifr.ifr_name); diff -Nuarp a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c --- a/net/ipv4/af_inet.c Tue Jan 6 20:40:06 2004 +++ b/net/ipv4/af_inet.c Tue Jan 6 20:40:08 2004 @@ -147,6 +147,16 @@ int (*br_ioctl_hook)(unsigned long); int (*vlan_ioctl_hook)(unsigned long arg); #endif +static DECLARE_MUTEX(bond_ioctl_mutex); +int (*bond_ioctl_hook)(unsigned long arg); + +void bond_ioctl_set(int (*hook)(unsigned long)) +{ + down(&bond_ioctl_mutex); + bond_ioctl_hook = hook; + up(&bond_ioctl_mutex); +} + /* The inetsw table contains everything that inet_create needs to * build a new socket. */ @@ -924,6 +934,21 @@ int inet_ioctl(struct socket *sock, unsi #endif return -ENOPKG; + case SIOCBONDING: + err = -ENOPKG; + +#ifdef CONFIG_KMOD + if (bond_ioctl_hook == NULL) + request_module("bonding"); +#endif + + down(&bond_ioctl_mutex); + if (bond_ioctl_hook != NULL) + err = bond_ioctl_hook(arg); + up(&bond_ioctl_mutex); + + return err; + default: if ((cmd >= SIOCDEVPRIVATE) && (cmd <= (SIOCDEVPRIVATE + 15))) diff -Nuarp a/net/netsyms.c b/net/netsyms.c --- a/net/netsyms.c Tue Jan 6 20:40:06 2004 +++ b/net/netsyms.c Tue Jan 6 20:40:08 2004 @@ -296,6 +296,9 @@ extern int (*dlci_ioctl_hook)(unsigned i EXPORT_SYMBOL(dlci_ioctl_hook); #endif +extern void bond_ioctl_set(int (*hook)(unsigned long)); +EXPORT_SYMBOL(bond_ioctl_set); + #if defined (CONFIG_IPV6_MODULE) || defined (CONFIG_KHTTPD) || defined (CONFIG_KHTTPD_MODULE) || defined (CONFIG_IP_SCTP_MODULE) /* inet functions common to v4 and v6 */ From amir.noam@intel.com Thu Jan 8 08:23:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:23:41 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GNMTa011219 for ; Thu, 8 Jan 2004 08:23:24 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08GN7ek012261; Thu, 8 Jan 2004 16:23:07 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08GN7xV000973; Thu, 8 Jan 2004 16:23:07 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010818230719136 ; Thu, 08 Jan 2004 18:23:07 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08GN6hb003877; Thu, 8 Jan 2004 18:23:07 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 2/4] [bonding 2.4] Reduce usage of the global Date: Thu, 8 Jan 2004 18:23:05 +0200 User-Agent: KMail/1.5.3 Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081823.06694.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2275 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 6428 Lines: 190 - Reduce usage of the global values of the ABI version received from the application. Instead, pass it as a function argument were needed. - Save a new slave's original HW address regardless of ABI version. - Move the clearing of the bond's address and some references to the bond's params structure so they are protected by the relevant locks. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Thu Jan 8 18:03:19 2004 +++ b/drivers/net/bonding/bond_main.c Thu Jan 8 18:03:21 2004 @@ -561,6 +561,11 @@ static int arp_ip_count = 0; static u32 my_ip = 0; static int bond_mode = BOND_MODE_ROUNDROBIN; static int lacp_fast = 0; + +/* The global abi_ver vars are only for providing backward compatibility with + * versions that locked bonding into using only the first abi_ver it has seen + * from userspace. + */ static int app_abi_ver = 0; static int orig_app_abi_ver = -1; /* This is used to save the first ABI version * we receive from the application. Once set, @@ -1207,7 +1212,7 @@ static int bond_sethwaddr(struct net_dev } /* enslave device to bond device */ -static int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev) +static int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev, int abi_ver) { struct bonding *bond = bond_dev->priv; struct slave *new_slave = NULL; @@ -1234,7 +1239,7 @@ static int bond_enslave(struct net_devic return -EBUSY; } - if (app_abi_ver >= 1) { + if (abi_ver >= 1) { /* The application is using an ABI, which requires the * slave interface to be closed. */ @@ -1289,13 +1294,12 @@ static int bond_enslave(struct net_devic */ new_slave->original_flags = slave_dev->flags; - if (app_abi_ver >= 1) { - /* save slave's original ("permanent") mac address for - * modes that needs it, and for restoring it upon release, - * and then set it to the master's address - */ - memcpy(new_slave->perm_hwaddr, slave_dev->dev_addr, ETH_ALEN); + /* save slave's original ("permanent") mac address for restoring it + * upon release + */ + memcpy(new_slave->perm_hwaddr, slave_dev->dev_addr, ETH_ALEN); + if (abi_ver >= 1) { /* set slave to master's mac address * The application already set the master's * mac address to that of the first slave @@ -1319,7 +1323,7 @@ static int bond_enslave(struct net_devic res = netdev_set_master(slave_dev, bond_dev); if (res) { dprintk("Error %d calling netdev_set_master\n", res); - if (app_abi_ver < 1) { + if (abi_ver < 1) { goto err_free; } else { goto err_close; @@ -1520,7 +1524,7 @@ static int bond_enslave(struct net_devic write_unlock_bh(&bond->lock); - if (app_abi_ver < 1) { + if (abi_ver < 1) { /* * !!! This is to support old versions of ifenslave. * We can remove this in 2.5 because our ifenslave takes @@ -1689,6 +1693,14 @@ static int bond_release(struct net_devic } } + if (bond->slave_cnt == 0) { + /* if the last slave was removed, zero the mac address + * of the master so it will be set by the application + * to the mac address of the first slave + */ + memset(bond_dev->dev_addr, 0, bond_dev->addr_len); + } + write_unlock_bh(&bond->lock); /* If the mode USES_PRIMARY, then we should only remove its @@ -1715,12 +1727,10 @@ static int bond_release(struct net_devic /* close slave before restoring its mac address */ dev_close(slave_dev); - if (app_abi_ver >= 1) { - /* restore original ("permanent") mac address */ - memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); - addr.sa_family = slave_dev->type; - slave_dev->set_mac_address(slave_dev, &addr); - } + /* restore original ("permanent") mac address */ + memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); + addr.sa_family = slave_dev->type; + slave_dev->set_mac_address(slave_dev, &addr); /* restore the original state of the * IFF_NOARP flag that might have been @@ -1732,14 +1742,6 @@ static int bond_release(struct net_devic kfree(slave); - /* if the last slave was removed, zero the mac address - * of the master so it will be set by the application - * to the mac address of the first slave - */ - if (bond->slave_cnt == 0) { - memset(bond_dev->dev_addr, 0, bond_dev->addr_len); - } - return 0; /* deletion OK */ } @@ -1812,12 +1814,10 @@ static int bond_release_all(struct net_d /* close slave before restoring its mac address */ dev_close(slave_dev); - if (app_abi_ver >= 1) { - /* restore original ("permanent") mac address*/ - memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); - addr.sa_family = slave_dev->type; - slave_dev->set_mac_address(slave_dev, &addr); - } + /* restore original ("permanent") mac address*/ + memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); + addr.sa_family = slave_dev->type; + slave_dev->set_mac_address(slave_dev, &addr); /* restore the original state of the IFF_NOARP flag that might have * been set by bond_set_slave_inactive_flags() @@ -1958,10 +1958,9 @@ static int bond_info_query(struct net_de { struct bonding *bond = bond_dev->priv; + read_lock_bh(&bond->lock); info->bond_mode = bond->params.mode; info->miimon = bond->params.miimon; - - read_lock_bh(&bond->lock); info->num_slaves = bond->slave_cnt; read_unlock_bh(&bond->lock); @@ -2754,16 +2753,14 @@ static void bond_info_show_slave(struct seq_printf(seq, "Link Failure Count: %d\n", slave->link_failure_count); - if (app_abi_ver >= 1) { - seq_printf(seq, - "Permanent HW addr: %02x:%02x:%02x:%02x:%02x:%02x\n", - slave->perm_hwaddr[0], - slave->perm_hwaddr[1], - slave->perm_hwaddr[2], - slave->perm_hwaddr[3], - slave->perm_hwaddr[4], - slave->perm_hwaddr[5]); - } + seq_printf(seq, + "Permanent HW addr: %02x:%02x:%02x:%02x:%02x:%02x\n", + slave->perm_hwaddr[0], + slave->perm_hwaddr[1], + slave->perm_hwaddr[2], + slave->perm_hwaddr[3], + slave->perm_hwaddr[4], + slave->perm_hwaddr[5]); if (bond->params.mode == BOND_MODE_8023AD) { const struct aggregator *agg @@ -3326,7 +3323,7 @@ static int bond_do_ioctl(struct net_devi switch (cmd) { case BOND_ENSLAVE_OLD: case SIOCBONDENSLAVE: - res = bond_enslave(bond_dev, slave_dev); + res = bond_enslave(bond_dev, slave_dev, app_abi_ver); break; case BOND_RELEASE_OLD: case SIOCBONDRELEASE: From amir.noam@intel.com Thu Jan 8 08:24:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:24:47 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GOVTa011329 for ; Thu, 8 Jan 2004 08:24:33 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08GOHek012540; Thu, 8 Jan 2004 16:24:17 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08GNpxf001065; Thu, 8 Jan 2004 16:24:17 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010818241619202 ; Thu, 08 Jan 2004 18:24:16 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08GOFhb003904; Thu, 8 Jan 2004 18:24:16 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 3/4] [bonding 2.4] Add support for the bond_hook in bonding Date: Thu, 8 Jan 2004 18:24:14 +0200 User-Agent: KMail/1.5.3 Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081824.15833.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2276 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 3246 Lines: 126 Add support for the bond_hook in bonding, and use it to export some parameters to the calling app. These parameters will be needed later by the application for dynamic configuration of bonding interfaces. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Thu Jan 8 18:03:23 2004 +++ b/drivers/net/bonding/bond_main.c Thu Jan 8 18:03:25 2004 @@ -599,6 +599,7 @@ static struct bond_parm_tbl bond_mode_tb /*-------------------------- Forward declarations ---------------------------*/ +extern void bond_ioctl_set(int (*hook)(unsigned long)); static inline void bond_set_mode_ops(struct net_device *bond_dev, int mode); /*---------------------------- General routines -----------------------------*/ @@ -3899,6 +3900,57 @@ static void bond_free_all(void) #endif } +static int bond_ioctl_deviceless(unsigned long arg) +{ + void *addr = (void *)arg; + u32 cmd; + + if (!capable(CAP_NET_ADMIN)) { + return -EPERM; + } + + if (get_user(cmd, (u32 *)addr)) { + return -EFAULT; + } + + switch (cmd) { + case BOND_CMD_DRV_INFO: { + struct bond_ioctl_drv_info drvinfo; + + if (copy_from_user(&drvinfo, addr, sizeof(drvinfo))) { + return -EFAULT; + } + + /* This is for backward compatibility only. + * Unconditionaly set both global abi_ver vars so we can block + * old ioctls in bond_do_ioctl(). + */ + orig_app_abi_ver = drvinfo.abi_ver; + app_abi_ver = drvinfo.abi_ver; + + drvinfo.abi_ver = BOND_ABI_VERSION; + drvinfo.num_prms = 0; + drvinfo.num_arp_targets = BOND_MAX_ARP_TARGETS; + + if (copy_to_user(addr, &drvinfo, sizeof(drvinfo))) { + return -EFAULT; + } + + break; + } + + /* TODO: implement dynamic add/del of bond interfaces + case BOND_CMD_ADD_BOND: + case BOND_CMD_DEL_BOND: + */ + + default: + return -EOPNOTSUPP; + } + + return 0; +} + /*------------------------- Module initialization ---------------------------*/ /* @@ -4220,6 +4272,8 @@ static int __init bonding_init(void) } rtnl_unlock(); + + bond_ioctl_set(bond_ioctl_deviceless); register_netdevice_notifier(&bond_netdev_notifier); return 0; @@ -4236,6 +4290,7 @@ out_err: static void __exit bonding_exit(void) { unregister_netdevice_notifier(&bond_netdev_notifier); + bond_ioctl_set(NULL); rtnl_lock(); bond_free_all(); diff -Nuarp a/include/linux/if_bonding.h b/include/linux/if_bonding.h --- a/include/linux/if_bonding.h Thu Jan 8 18:03:23 2004 +++ b/include/linux/if_bonding.h Thu Jan 8 18:03:25 2004 @@ -103,6 +103,30 @@ struct ad_info { __u8 partner_system[ETH_ALEN]; }; + +/* + * The following are the available command codes for the SIOCBONDING and + * SIOCBONDDEVICE ioctls. The command codes are the first u32 value of the + * passed struct. The second u32 value is the ABI version of the application. + */ +#define BOND_CMD_DRV_INFO 0x00000001 +#define BOND_CMD_ADD_BOND 0x00000002 +#define BOND_CMD_DEL_BOND 0x00000003 + +/** + * bond_ioctl_drv_info + * + * Used by the %BOND_CMD_DRV_INFO command to retrieve some parameters of the + * bonding driver. + */ +struct bond_ioctl_drv_info { + __u32 cmd; + __u32 abi_ver; + __u32 num_prms; + __u32 num_arp_targets; + char reserved[32]; +}; + #endif /* _LINUX_IF_BONDING_H */ /* From amir.noam@intel.com Thu Jan 8 08:26:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:26:26 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GQATa011978 for ; Thu, 8 Jan 2004 08:26:12 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08GPuek012721; Thu, 8 Jan 2004 16:25:56 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08GPtxV001284; Thu, 8 Jan 2004 16:25:55 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010818255519237 ; Thu, 08 Jan 2004 18:25:55 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08GPshb003949; Thu, 8 Jan 2004 18:25:55 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 4/4] [bonding 2.4] Support old commands over new bonding ioctl Date: Thu, 8 Jan 2004 18:25:53 +0200 User-Agent: KMail/1.5.3 Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081825.54932.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2277 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 4415 Lines: 177 Support old commands (enslave, release, change-active) over the new bonding ioctl (SIOCBONDDEVICE). diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Thu Jan 8 18:03:27 2004 +++ b/drivers/net/bonding/bond_main.c Thu Jan 8 18:03:29 2004 @@ -1955,6 +1955,86 @@ static int bond_ethtool_ioctl(struct net } } +static int bond_ioctl_slave_dev(struct bonding *bond, int cmd, void *addr) +{ + struct bond_ioctl_cmd bond_cmd; + struct net_device *slave_dev; + int prev_abi_ver = app_abi_ver; + int prev_orig_abi_ver = orig_app_abi_ver; + int res = 0; + + if (copy_from_user(&bond_cmd, addr, sizeof(bond_cmd))) { + return -EFAULT; + } + + bond_cmd.ifname[IFNAMSIZ - 1] = 0; + + slave_dev = dev_get_by_name(bond_cmd.ifname); + if (!slave_dev) { + return -ENODEV; + } + + /* This is for backward compatibility only. + * Unconditionaly set both global abi_ver vars so we can block + * old ioctls in bond_do_ioctl(). + */ + orig_app_abi_ver = bond_cmd.abi_ver; + app_abi_ver = bond_cmd.abi_ver; + + switch (cmd) { + case BOND_CMD_ENSLAVE: + res = bond_enslave(bond->dev, slave_dev, bond_cmd.abi_ver); + break; + + case BOND_CMD_RELEASE: + res = bond_release(bond->dev, slave_dev); + break; + + case BOND_CMD_CHANGE_ACTIVE: + res = bond_ioctl_change_active(bond->dev, slave_dev); + break; + + default: + res = -EOPNOTSUPP; + break; + } + + dev_put(slave_dev); + + if (res < 0) { + /* The ioctl failed, so there's no point in changing the + * orig_app_abi_ver. We'll restore it's value just in case + * we've changed it earlier in this function. + */ + app_abi_ver = prev_abi_ver; + orig_app_abi_ver = prev_orig_abi_ver; + } + + return res; +} + +static int bond_ioctl_device(struct bonding *bond, void *addr) +{ + u32 cmd; + + if (get_user(cmd, (u32 *) addr)) { + return -EFAULT; + } + + switch (cmd) { + case BOND_CMD_ENSLAVE: + case BOND_CMD_RELEASE: + case BOND_CMD_CHANGE_ACTIVE: + /* these ioctl cmds receive a slave name as an arg */ + return bond_ioctl_slave_dev(bond, cmd, addr); + + default: + return -EOPNOTSUPP; + } + + return 0; +} + static int bond_info_query(struct net_device *bond_dev, struct ifbond *info) { struct bonding *bond = bond_dev->priv; @@ -3214,6 +3294,7 @@ static struct net_device_stats *bond_get static int bond_do_ioctl(struct net_device *bond_dev, struct ifreq *ifr, int cmd) { + struct bonding *bond = bond_dev->priv; struct net_device *slave_dev = NULL; struct ifbond *u_binfo = NULL, k_binfo; struct ifslave *u_sinfo = NULL, k_sinfo; @@ -3224,6 +3305,10 @@ static int bond_do_ioctl(struct net_devi dprintk("bond_ioctl: master=%s, cmd=%d\n", bond_dev->name, cmd); + if (!capable(CAP_NET_ADMIN)) { + return -EPERM; + } + switch (cmd) { case SIOCETHTOOL: return bond_ethtool_ioctl(bond_dev, ifr); @@ -3245,7 +3330,6 @@ static int bond_do_ioctl(struct net_devi } if (mii->reg_num == 1) { - struct bonding *bond = bond_dev->priv; mii->val_out = 0; read_lock_bh(&bond->lock); read_lock(&bond->curr_slave_lock); @@ -3289,13 +3373,19 @@ static int bond_do_ioctl(struct net_devi } return res; + case SIOCBONDDEVICE: + return bond_ioctl_device(bond, ifr->ifr_data); + default: /* Go on */ break; } - if (!capable(CAP_NET_ADMIN)) { - return -EPERM; + if (orig_app_abi_ver > 2) { + /* Refuse to support old ioctls if the app has already + * declared it is new enough for SIOCBONDDEVICE commands. + */ + return -EOPNOTSUPP; } if (orig_app_abi_ver == -1) { diff -Nuarp a/include/linux/if_bonding.h b/include/linux/if_bonding.h --- a/include/linux/if_bonding.h Thu Jan 8 18:03:27 2004 +++ b/include/linux/if_bonding.h Thu Jan 8 18:03:29 2004 @@ -112,6 +112,9 @@ struct ad_info { #define BOND_CMD_DRV_INFO 0x00000001 #define BOND_CMD_ADD_BOND 0x00000002 #define BOND_CMD_DEL_BOND 0x00000003 +#define BOND_CMD_ENSLAVE 0x00000004 +#define BOND_CMD_RELEASE 0x00000005 +#define BOND_CMD_CHANGE_ACTIVE 0x00000006 /** * bond_ioctl_drv_info @@ -127,6 +130,19 @@ struct bond_ioctl_drv_info { char reserved[32]; }; +/** + * bond_ioctl_cmd + * + * %BOND_CMD_ENSLAVE, %BOND_CMD_RELEASE and %BOND_CMD_CHANGE_ACTIVE pass the + * name of the slave to work on in @ifname. + */ +struct bond_ioctl_cmd { + __u32 cmd; + __u32 abi_ver; + __u32 num_prms; + char ifname[IFNAMSIZ]; +}; + #endif /* _LINUX_IF_BONDING_H */ /* From amir.noam@intel.com Thu Jan 8 08:29:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:29:26 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GT9Ta012484 for ; Thu, 8 Jan 2004 08:29:11 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08GStek012962; Thu, 8 Jan 2004 16:28:55 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08GStxV001443; Thu, 8 Jan 2004 16:28:55 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010818285519276 ; Thu, 08 Jan 2004 18:28:55 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08GSthb004000; Thu, 8 Jan 2004 18:28:55 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 2/4] [bonding 2.6] Reduce usage of the global value of abi_ver Date: Thu, 8 Jan 2004 18:28:53 +0200 User-Agent: KMail/1.5.3 Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081828.54991.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2278 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 6428 Lines: 190 - Reduce usage of the global values of the ABI version received from the application. Instead, pass it as a function argument were needed. - Save a new slave's original HW address regardless of ABI version. - Move the clearing of the bond's address and some references to the bond's params structure so they are protected by the relevant locks. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Thu Jan 8 18:06:45 2004 +++ b/drivers/net/bonding/bond_main.c Thu Jan 8 18:06:46 2004 @@ -561,6 +561,11 @@ static int arp_ip_count = 0; static u32 my_ip = 0; static int bond_mode = BOND_MODE_ROUNDROBIN; static int lacp_fast = 0; + +/* The global abi_ver vars are only for providing backward compatibility with + * versions that locked bonding into using only the first abi_ver it has seen + * from userspace. + */ static int app_abi_ver = 0; static int orig_app_abi_ver = -1; /* This is used to save the first ABI version * we receive from the application. Once set, @@ -1207,7 +1212,7 @@ static int bond_sethwaddr(struct net_dev } /* enslave device to bond device */ -static int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev) +static int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev, int abi_ver) { struct bonding *bond = bond_dev->priv; struct slave *new_slave = NULL; @@ -1234,7 +1239,7 @@ static int bond_enslave(struct net_devic return -EBUSY; } - if (app_abi_ver >= 1) { + if (abi_ver >= 1) { /* The application is using an ABI, which requires the * slave interface to be closed. */ @@ -1289,13 +1294,12 @@ static int bond_enslave(struct net_devic */ new_slave->original_flags = slave_dev->flags; - if (app_abi_ver >= 1) { - /* save slave's original ("permanent") mac address for - * modes that needs it, and for restoring it upon release, - * and then set it to the master's address - */ - memcpy(new_slave->perm_hwaddr, slave_dev->dev_addr, ETH_ALEN); + /* save slave's original ("permanent") mac address for restoring it + * upon release + */ + memcpy(new_slave->perm_hwaddr, slave_dev->dev_addr, ETH_ALEN); + if (abi_ver >= 1) { /* set slave to master's mac address * The application already set the master's * mac address to that of the first slave @@ -1319,7 +1323,7 @@ static int bond_enslave(struct net_devic res = netdev_set_master(slave_dev, bond_dev); if (res) { dprintk("Error %d calling netdev_set_master\n", res); - if (app_abi_ver < 1) { + if (abi_ver < 1) { goto err_free; } else { goto err_close; @@ -1520,7 +1524,7 @@ static int bond_enslave(struct net_devic write_unlock_bh(&bond->lock); - if (app_abi_ver < 1) { + if (abi_ver < 1) { /* * !!! This is to support old versions of ifenslave. * We can remove this in 2.5 because our ifenslave takes @@ -1689,6 +1693,14 @@ static int bond_release(struct net_devic } } + if (bond->slave_cnt == 0) { + /* if the last slave was removed, zero the mac address + * of the master so it will be set by the application + * to the mac address of the first slave + */ + memset(bond_dev->dev_addr, 0, bond_dev->addr_len); + } + write_unlock_bh(&bond->lock); /* If the mode USES_PRIMARY, then we should only remove its @@ -1715,12 +1727,10 @@ static int bond_release(struct net_devic /* close slave before restoring its mac address */ dev_close(slave_dev); - if (app_abi_ver >= 1) { - /* restore original ("permanent") mac address */ - memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); - addr.sa_family = slave_dev->type; - slave_dev->set_mac_address(slave_dev, &addr); - } + /* restore original ("permanent") mac address */ + memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); + addr.sa_family = slave_dev->type; + slave_dev->set_mac_address(slave_dev, &addr); /* restore the original state of the * IFF_NOARP flag that might have been @@ -1732,14 +1742,6 @@ static int bond_release(struct net_devic kfree(slave); - /* if the last slave was removed, zero the mac address - * of the master so it will be set by the application - * to the mac address of the first slave - */ - if (bond->slave_cnt == 0) { - memset(bond_dev->dev_addr, 0, bond_dev->addr_len); - } - return 0; /* deletion OK */ } @@ -1812,12 +1814,10 @@ static int bond_release_all(struct net_d /* close slave before restoring its mac address */ dev_close(slave_dev); - if (app_abi_ver >= 1) { - /* restore original ("permanent") mac address*/ - memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); - addr.sa_family = slave_dev->type; - slave_dev->set_mac_address(slave_dev, &addr); - } + /* restore original ("permanent") mac address*/ + memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); + addr.sa_family = slave_dev->type; + slave_dev->set_mac_address(slave_dev, &addr); /* restore the original state of the IFF_NOARP flag that might have * been set by bond_set_slave_inactive_flags() @@ -1958,10 +1958,9 @@ static int bond_info_query(struct net_de { struct bonding *bond = bond_dev->priv; + read_lock_bh(&bond->lock); info->bond_mode = bond->params.mode; info->miimon = bond->params.miimon; - - read_lock_bh(&bond->lock); info->num_slaves = bond->slave_cnt; read_unlock_bh(&bond->lock); @@ -2754,16 +2753,14 @@ static void bond_info_show_slave(struct seq_printf(seq, "Link Failure Count: %d\n", slave->link_failure_count); - if (app_abi_ver >= 1) { - seq_printf(seq, - "Permanent HW addr: %02x:%02x:%02x:%02x:%02x:%02x\n", - slave->perm_hwaddr[0], - slave->perm_hwaddr[1], - slave->perm_hwaddr[2], - slave->perm_hwaddr[3], - slave->perm_hwaddr[4], - slave->perm_hwaddr[5]); - } + seq_printf(seq, + "Permanent HW addr: %02x:%02x:%02x:%02x:%02x:%02x\n", + slave->perm_hwaddr[0], + slave->perm_hwaddr[1], + slave->perm_hwaddr[2], + slave->perm_hwaddr[3], + slave->perm_hwaddr[4], + slave->perm_hwaddr[5]); if (bond->params.mode == BOND_MODE_8023AD) { const struct aggregator *agg @@ -3325,7 +3322,7 @@ static int bond_do_ioctl(struct net_devi switch (cmd) { case BOND_ENSLAVE_OLD: case SIOCBONDENSLAVE: - res = bond_enslave(bond_dev, slave_dev); + res = bond_enslave(bond_dev, slave_dev, app_abi_ver); break; case BOND_RELEASE_OLD: case SIOCBONDRELEASE: From amir.noam@intel.com Thu Jan 8 08:30:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:30:27 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GU9Ta012543 for ; Thu, 8 Jan 2004 08:30:11 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08GTtek013040; Thu, 8 Jan 2004 16:29:55 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08GTsxV001508; Thu, 8 Jan 2004 16:29:55 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010818295419288 ; Thu, 08 Jan 2004 18:29:54 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08GTshb004033; Thu, 8 Jan 2004 18:29:54 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 3/4] [bonding 2.6] Add support for the bond_hook in bonding Date: Thu, 8 Jan 2004 18:29:53 +0200 User-Agent: KMail/1.5.3 Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081829.54372.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2279 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 3246 Lines: 126 Add support for the bond_hook in bonding, and use it to export some parameters to the calling app. These parameters will be needed later by the application for dynamic configuration of bonding interfaces. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Thu Jan 8 18:06:49 2004 +++ b/drivers/net/bonding/bond_main.c Thu Jan 8 18:06:50 2004 @@ -599,6 +599,7 @@ static struct bond_parm_tbl bond_mode_tb /*-------------------------- Forward declarations ---------------------------*/ +extern void bond_ioctl_set(int (*hook)(unsigned long)); static inline void bond_set_mode_ops(struct net_device *bond_dev, int mode); /*---------------------------- General routines -----------------------------*/ @@ -3898,6 +3899,57 @@ static void bond_free_all(void) #endif } +static int bond_ioctl_deviceless(unsigned long arg) +{ + void *addr = (void *)arg; + u32 cmd; + + if (!capable(CAP_NET_ADMIN)) { + return -EPERM; + } + + if (get_user(cmd, (u32 *)addr)) { + return -EFAULT; + } + + switch (cmd) { + case BOND_CMD_DRV_INFO: { + struct bond_ioctl_drv_info drvinfo; + + if (copy_from_user(&drvinfo, addr, sizeof(drvinfo))) { + return -EFAULT; + } + + /* This is for backward compatibility only. + * Unconditionaly set both global abi_ver vars so we can block + * old ioctls in bond_do_ioctl(). + */ + orig_app_abi_ver = drvinfo.abi_ver; + app_abi_ver = drvinfo.abi_ver; + + drvinfo.abi_ver = BOND_ABI_VERSION; + drvinfo.num_prms = 0; + drvinfo.num_arp_targets = BOND_MAX_ARP_TARGETS; + + if (copy_to_user(addr, &drvinfo, sizeof(drvinfo))) { + return -EFAULT; + } + + break; + } + + /* TODO: implement dynamic add/del of bond interfaces + case BOND_CMD_ADD_BOND: + case BOND_CMD_DEL_BOND: + */ + + default: + return -EOPNOTSUPP; + } + + return 0; +} + /*------------------------- Module initialization ---------------------------*/ /* @@ -4219,6 +4271,8 @@ static int __init bonding_init(void) } rtnl_unlock(); + + bond_ioctl_set(bond_ioctl_deviceless); register_netdevice_notifier(&bond_netdev_notifier); return 0; @@ -4235,6 +4289,7 @@ out_err: static void __exit bonding_exit(void) { unregister_netdevice_notifier(&bond_netdev_notifier); + bond_ioctl_set(NULL); rtnl_lock(); bond_free_all(); diff -Nuarp a/include/linux/if_bonding.h b/include/linux/if_bonding.h --- a/include/linux/if_bonding.h Thu Jan 8 18:06:49 2004 +++ b/include/linux/if_bonding.h Thu Jan 8 18:06:50 2004 @@ -103,6 +103,30 @@ struct ad_info { __u8 partner_system[ETH_ALEN]; }; + +/* + * The following are the available command codes for the SIOCBONDING and + * SIOCBONDDEVICE ioctls. The command codes are the first u32 value of the + * passed struct. The second u32 value is the ABI version of the application. + */ +#define BOND_CMD_DRV_INFO 0x00000001 +#define BOND_CMD_ADD_BOND 0x00000002 +#define BOND_CMD_DEL_BOND 0x00000003 + +/** + * bond_ioctl_drv_info + * + * Used by the %BOND_CMD_DRV_INFO command to retrieve some parameters of the + * bonding driver. + */ +struct bond_ioctl_drv_info { + __u32 cmd; + __u32 abi_ver; + __u32 num_prms; + __u32 num_arp_targets; + char reserved[32]; +}; + #endif /* _LINUX_IF_BONDING_H */ /* From amir.noam@intel.com Thu Jan 8 08:31:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:31:32 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GVDTa012934 for ; Thu, 8 Jan 2004 08:31:15 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08GUwek013210; Thu, 8 Jan 2004 16:30:58 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08GUwxX001629; Thu, 8 Jan 2004 16:30:58 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010818305719342 ; Thu, 08 Jan 2004 18:30:57 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08GUthb004074; Thu, 8 Jan 2004 18:30:56 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 4/4] [bonding 2.6] Support old commands over new bonding ioctl Date: Thu, 8 Jan 2004 18:30:55 +0200 User-Agent: KMail/1.5.3 Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081830.55891.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2280 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 4415 Lines: 177 Support old commands (enslave, release, change-active) over the new bonding ioctl (SIOCBONDDEVICE). diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Thu Jan 8 18:06:53 2004 +++ b/drivers/net/bonding/bond_main.c Thu Jan 8 18:06:54 2004 @@ -1955,6 +1955,86 @@ static int bond_ethtool_ioctl(struct net } } +static int bond_ioctl_slave_dev(struct bonding *bond, int cmd, void *addr) +{ + struct bond_ioctl_cmd bond_cmd; + struct net_device *slave_dev; + int prev_abi_ver = app_abi_ver; + int prev_orig_abi_ver = orig_app_abi_ver; + int res = 0; + + if (copy_from_user(&bond_cmd, addr, sizeof(bond_cmd))) { + return -EFAULT; + } + + bond_cmd.ifname[IFNAMSIZ - 1] = 0; + + slave_dev = dev_get_by_name(bond_cmd.ifname); + if (!slave_dev) { + return -ENODEV; + } + + /* This is for backward compatibility only. + * Unconditionaly set both global abi_ver vars so we can block + * old ioctls in bond_do_ioctl(). + */ + orig_app_abi_ver = bond_cmd.abi_ver; + app_abi_ver = bond_cmd.abi_ver; + + switch (cmd) { + case BOND_CMD_ENSLAVE: + res = bond_enslave(bond->dev, slave_dev, bond_cmd.abi_ver); + break; + + case BOND_CMD_RELEASE: + res = bond_release(bond->dev, slave_dev); + break; + + case BOND_CMD_CHANGE_ACTIVE: + res = bond_ioctl_change_active(bond->dev, slave_dev); + break; + + default: + res = -EOPNOTSUPP; + break; + } + + dev_put(slave_dev); + + if (res < 0) { + /* The ioctl failed, so there's no point in changing the + * orig_app_abi_ver. We'll restore it's value just in case + * we've changed it earlier in this function. + */ + app_abi_ver = prev_abi_ver; + orig_app_abi_ver = prev_orig_abi_ver; + } + + return res; +} + +static int bond_ioctl_device(struct bonding *bond, void *addr) +{ + u32 cmd; + + if (get_user(cmd, (u32 *) addr)) { + return -EFAULT; + } + + switch (cmd) { + case BOND_CMD_ENSLAVE: + case BOND_CMD_RELEASE: + case BOND_CMD_CHANGE_ACTIVE: + /* these ioctl cmds receive a slave name as an arg */ + return bond_ioctl_slave_dev(bond, cmd, addr); + + default: + return -EOPNOTSUPP; + } + + return 0; +} + static int bond_info_query(struct net_device *bond_dev, struct ifbond *info) { struct bonding *bond = bond_dev->priv; @@ -3213,6 +3293,7 @@ static struct net_device_stats *bond_get static int bond_do_ioctl(struct net_device *bond_dev, struct ifreq *ifr, int cmd) { + struct bonding *bond = bond_dev->priv; struct net_device *slave_dev = NULL; struct ifbond *u_binfo = NULL, k_binfo; struct ifslave *u_sinfo = NULL, k_sinfo; @@ -3223,6 +3304,10 @@ static int bond_do_ioctl(struct net_devi dprintk("bond_ioctl: master=%s, cmd=%d\n", bond_dev->name, cmd); + if (!capable(CAP_NET_ADMIN)) { + return -EPERM; + } + switch (cmd) { case SIOCETHTOOL: return bond_ethtool_ioctl(bond_dev, ifr); @@ -3244,7 +3329,6 @@ static int bond_do_ioctl(struct net_devi } if (mii->reg_num == 1) { - struct bonding *bond = bond_dev->priv; mii->val_out = 0; read_lock_bh(&bond->lock); read_lock(&bond->curr_slave_lock); @@ -3288,13 +3372,19 @@ static int bond_do_ioctl(struct net_devi } return res; + case SIOCBONDDEVICE: + return bond_ioctl_device(bond, ifr->ifr_data); + default: /* Go on */ break; } - if (!capable(CAP_NET_ADMIN)) { - return -EPERM; + if (orig_app_abi_ver > 2) { + /* Refuse to support old ioctls if the app has already + * declared it is new enough for SIOCBONDDEVICE commands. + */ + return -EOPNOTSUPP; } if (orig_app_abi_ver == -1) { diff -Nuarp a/include/linux/if_bonding.h b/include/linux/if_bonding.h --- a/include/linux/if_bonding.h Thu Jan 8 18:06:53 2004 +++ b/include/linux/if_bonding.h Thu Jan 8 18:06:54 2004 @@ -112,6 +112,9 @@ struct ad_info { #define BOND_CMD_DRV_INFO 0x00000001 #define BOND_CMD_ADD_BOND 0x00000002 #define BOND_CMD_DEL_BOND 0x00000003 +#define BOND_CMD_ENSLAVE 0x00000004 +#define BOND_CMD_RELEASE 0x00000005 +#define BOND_CMD_CHANGE_ACTIVE 0x00000006 /** * bond_ioctl_drv_info @@ -127,6 +130,19 @@ struct bond_ioctl_drv_info { char reserved[32]; }; +/** + * bond_ioctl_cmd + * + * %BOND_CMD_ENSLAVE, %BOND_CMD_RELEASE and %BOND_CMD_CHANGE_ACTIVE pass the + * name of the slave to work on in @ifname. + */ +struct bond_ioctl_cmd { + __u32 cmd; + __u32 abi_ver; + __u32 num_prms; + char ifname[IFNAMSIZ]; +}; + #endif /* _LINUX_IF_BONDING_H */ /* From per@hedeland.org Thu Jan 8 08:44:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:44:19 -0800 (PST) Received: from pluto.hedeland.org (as1-2-8.mal.s.bonet.se [194.236.4.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08Gi4Ta014007 for ; Thu, 8 Jan 2004 08:44:05 -0800 Received: from pluto.hedeland.org (localhost [127.0.0.1]) by pluto.hedeland.org (8.12.10/8.12.10) with ESMTP id i08GhwI5059383 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 8 Jan 2004 17:43:58 +0100 (CET) Received: (from per@localhost) by pluto.hedeland.org (8.12.10/8.12.10/Submit) id i08GhwRP059382; Thu, 8 Jan 2004 17:43:58 +0100 (CET) Date: Thu, 8 Jan 2004 17:43:58 +0100 (CET) From: Per Hedeland Message-Id: <200401081643.i08GhwRP059382@pluto.hedeland.org> To: amir.noam@intel.com Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] [PATCH] [bonding 2.4] Add balance-xor-ip bonding mode In-Reply-To: <200401081733.44744.amir.noam@intel.com> X-archive-position: 2281 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: per@hedeland.org Precedence: bulk X-list: netdev Content-Length: 875 Lines: 24 Amir Noam wrote: >Please use u32 instead of __u32. OK. >hmm... > >I don't like this. The reason we give different tx function pointers >to dev->hard_start_xmit in different bonding mode is to make the tx >path as fast as possible. Otherwise we might as well use a single tx >function that chooses its exact operation based on the bonding mode. > >It might be better to have some code duplication if it results in >faster tx, but I'm not sure what's the optimal solution in this case. Well, I don't really have an opinion since I don't have a good idea about the cost of a function call relative to "everything else" that is happening here. I don't see a way to do "limited" duplication without using function calls though, but I'm quite happy to make it two entirely separate functions for MAC vs IP. Please advise. --Per Hedeland per@hedeland.org From chas@cmf.nrl.navy.mil Thu Jan 8 08:58:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:59:05 -0800 (PST) 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.9) with SMTP id i08GwpTa014932 for ; Thu, 8 Jan 2004 08:58:52 -0800 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 i08GwdRr017374; Thu, 8 Jan 2004 11:58:39 -0500 (EST) Message-Id: <200401081658.i08GwdRr017374@ginger.cmf.nrl.navy.mil> To: davem@redhat.com cc: netdev@oss.sgi.com, ajz@cambridgebroadband.com Subject: [PATCH][ATM]: br2684 incorrectly handles frames recvd with FCS (by Alex Zeffertt ) Reply-To: chas3@users.sourceforge.net Date: Thu, 08 Jan 2004 11:58:40 -0500 From: chas williams (contractor) X-Spam-Score: () hits=0.5 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 2282 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: 1076 Lines: 31 please apply to 2.6 (and 2.4 as well!) thanks # 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.1492 -> 1.1493 # net/atm/br2684.c 1.9 -> 1.10 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/01/07 chas@relax.cmf.nrl.navy.mil 1.1493 # [ATM]: br2684 incorrectly handles frames recvd with FCS (by Alex Zeffertt ) # -------------------------------------------- # diff -Nru a/net/atm/br2684.c b/net/atm/br2684.c --- a/net/atm/br2684.c Wed Jan 7 13:23:54 2004 +++ b/net/atm/br2684.c Wed Jan 7 13:23:54 2004 @@ -437,6 +437,10 @@ dev_kfree_skb(skb); return; } + + /* Strip FCS if present */ + if (skb->len > 7 && skb->data[7] == 0x01) + __skb_trim(skb, skb->len - 4); } else { plen = PADLEN + ETH_HLEN; /* pad, dstmac,srcmac, ethtype */ /* first 2 chars should be 0 */ From per@hedeland.org Thu Jan 8 08:59:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:59:41 -0800 (PST) Received: from pluto.hedeland.org (as1-2-8.mal.s.bonet.se [194.236.4.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GxRTa014960 for ; Thu, 8 Jan 2004 08:59:28 -0800 Received: from pluto.hedeland.org (localhost [127.0.0.1]) by pluto.hedeland.org (8.12.10/8.12.10) with ESMTP id i08GwXI5059632 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 8 Jan 2004 17:58:33 +0100 (CET) Received: (from per@localhost) by pluto.hedeland.org (8.12.10/8.12.10/Submit) id i08GwXZV059631; Thu, 8 Jan 2004 17:58:33 +0100 (CET) Date: Thu, 8 Jan 2004 17:58:33 +0100 (CET) From: Per Hedeland Message-Id: <200401081658.i08GwXZV059631@pluto.hedeland.org> To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, tony.cureington@hp.com Subject: RE: [Bonding-devel] [PATCH] [bonding 2.6] Add balance-xor-ip bonding mode In-Reply-To: <72A87F7160C0994D8C5A36E2FDC227F502B3E9BE@txnexc01.americas.cpqcorp.net> X-archive-position: 2283 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: per@hedeland.org Precedence: bulk X-list: netdev Content-Length: 711 Lines: 13 "Cureington, Tony" wrote: > >I'm curious of the reasoning behind "u ^= (u >> 24) ^ (u >> 16) ^ (u >> 8);", what advantages does it have over using the xor'd addresses just before this line? Maybe someone loaded decaf on me this morning? :-/ The idea is to take all octets of the addresses into account (similar logic is already used in bond_alb.c btw). E.g. if the number of slaves is a power of 2 (2 or 4 is probably very common), a full_address % num_slaves operation will effectively only use one octet (happens to be the first one on x86, which is probably the worst choice, but of course that could be compensated for). Or am I missing something? --Per Hedeland per@hedeland.org From amir.noam@intel.com Thu Jan 8 13:28:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 13:28:23 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LS0Ta027487 for ; Thu, 8 Jan 2004 13:28:04 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08GRSek012840; Thu, 8 Jan 2004 16:27:28 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08GRRxV001366; Thu, 8 Jan 2004 16:27:27 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010818272719257 ; Thu, 08 Jan 2004 18:27:27 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08GRQhb003985; Thu, 8 Jan 2004 18:27:27 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 1/4] [bonding 2.6] Add bonding ioctl hook Date: Thu, 8 Jan 2004 18:27:24 +0200 User-Agent: KMail/1.5.3 Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081827.26718.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2284 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 2706 Lines: 86 Add two bonding ioctls: SIOCBONDING: ioctl hook to handle commands not directed at a specific bond interface. SIOCBONDDEVICE: ioctl to handle commands for a bond interface. This ioctl can also handle all existing commands, so we can regard them as obsolete in the future. All future bonding operations will be a sub-command of one of these ioctls. diff -Nuarp a/include/linux/sockios.h b/include/linux/sockios.h --- a/include/linux/sockios.h Thu Jan 8 18:06:41 2004 +++ b/include/linux/sockios.h Thu Jan 8 18:06:42 2004 @@ -115,7 +115,9 @@ #define SIOCBONDSLAVEINFOQUERY 0x8993 /* rtn info about slave state */ #define SIOCBONDINFOQUERY 0x8994 /* rtn info about bond state */ #define SIOCBONDCHANGEACTIVE 0x8995 /* update to a new active slave */ - +#define SIOCBONDING 0x8996 /* deviceless bonding commands */ +#define SIOCBONDDEVICE 0x8997 /* device oriented bonding commands */ + /* Device private ioctl calls */ /* diff -Nuarp a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Thu Jan 8 18:06:41 2004 +++ b/net/core/dev.c Thu Jan 8 18:06:42 2004 @@ -2408,6 +2408,7 @@ static int dev_ifsioc(struct ifreq *ifr, cmd == SIOCBONDSLAVEINFOQUERY || cmd == SIOCBONDINFOQUERY || cmd == SIOCBONDCHANGEACTIVE || + cmd == SIOCBONDDEVICE || cmd == SIOCGMIIPHY || cmd == SIOCGMIIREG || cmd == SIOCSMIIREG || @@ -2565,6 +2566,7 @@ int dev_ioctl(unsigned int cmd, void *ar case SIOCBONDSLAVEINFOQUERY: case SIOCBONDINFOQUERY: case SIOCBONDCHANGEACTIVE: + case SIOCBONDDEVICE: if (!capable(CAP_NET_ADMIN)) return -EPERM; dev_load(ifr.ifr_name); diff -Nuarp a/net/socket.c b/net/socket.c --- a/net/socket.c Thu Jan 8 18:06:41 2004 +++ b/net/socket.c Thu Jan 8 18:06:42 2004 @@ -754,6 +754,17 @@ void dlci_ioctl_set(int (*hook)(unsigned } EXPORT_SYMBOL(dlci_ioctl_set); +static DECLARE_MUTEX(bond_ioctl_mutex); +static int (*bond_ioctl_hook)(unsigned long arg); + +void bond_ioctl_set(int (*hook)(unsigned long)) +{ + down(&bond_ioctl_mutex); + bond_ioctl_hook = hook; + up(&bond_ioctl_mutex); +} +EXPORT_SYMBOL(bond_ioctl_set); + /* * With an ioctl, arg may well be a user mode pointer, but we don't know * what to do with it - that's up to the protocol still. @@ -826,6 +837,17 @@ static int sock_ioctl(struct inode *inod up(&dlci_ioctl_mutex); } break; + case SIOCBONDING: + err = -ENOPKG; + if (!bond_ioctl_hook) + request_module("bonding"); + + down(&bond_ioctl_mutex); + if (bond_ioctl_hook) { + err = bond_ioctl_hook(arg); + } + up(&bond_ioctl_mutex); + break; default: err = sock->ops->ioctl(sock, cmd, arg); break; From shemminger@osdl.org Thu Jan 8 13:39:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 13:39:27 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LdCTa028019 for ; Thu, 8 Jan 2004 13:39:13 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08Ld1o03897; Thu, 8 Jan 2004 13:39:01 -0800 Date: Fri, 9 Jan 2004 13:39:50 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (2/17) ipv4/ipv6 - size_t for send/recvmsg Message-Id: <20040109133950.52e423fd@linux.local> X-Mailer: Sylpheed version 0.9.8claws (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: 2286 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 Content-Length: 10472 Lines: 314 Convert sendmsg/recvmsg from size as int to size as size_t. Remove comment in UDP that addresses this very issue. diff -Nru a/include/net/inet_common.h b/include/net/inet_common.h --- a/include/net/inet_common.h Fri Jan 9 13:38:06 2004 +++ b/include/net/inet_common.h Fri Jan 9 13:38:06 2004 @@ -23,11 +23,11 @@ extern int inet_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *ubuf, - int size, int flags); + size_t size, int flags); extern int inet_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int size); + size_t size); extern int inet_shutdown(struct socket *sock, int how); extern unsigned int inet_poll(struct file * file, struct socket *sock, struct poll_table_struct *wait); extern int inet_setsockopt(struct socket *sock, int level, diff -Nru a/include/net/tcp.h b/include/net/tcp.h --- a/include/net/tcp.h Fri Jan 9 13:38:06 2004 +++ b/include/net/tcp.h Fri Jan 9 13:38:06 2004 @@ -752,7 +752,7 @@ extern int tcp_v4_tw_remember_stamp(struct tcp_tw_bucket *tw); extern int tcp_sendmsg(struct kiocb *iocb, struct sock *sk, - struct msghdr *msg, int size); + struct msghdr *msg, size_t size); extern ssize_t tcp_sendpage(struct socket *sock, struct page *page, int offset, size_t size, int flags); extern int tcp_ioctl(struct sock *sk, @@ -846,7 +846,7 @@ extern void tcp_set_keepalive(struct sock *sk, int val); extern int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, - int len, int nonblock, + size_t len, int nonblock, int flags, int *addr_len); extern int tcp_listen_start(struct sock *sk); diff -Nru a/include/net/udp.h b/include/net/udp.h --- a/include/net/udp.h Fri Jan 9 13:38:06 2004 +++ b/include/net/udp.h Fri Jan 9 13:38:06 2004 @@ -68,7 +68,7 @@ struct sockaddr *usin, int addr_len); extern int udp_sendmsg(struct kiocb *iocb, struct sock *sk, - struct msghdr *msg, int len); + struct msghdr *msg, size_t len); extern int udp_rcv(struct sk_buff *skb); extern int udp_ioctl(struct sock *sk, int cmd, unsigned long arg); diff -Nru a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c --- a/net/ipv4/af_inet.c Fri Jan 9 13:38:06 2004 +++ b/net/ipv4/af_inet.c Fri Jan 9 13:38:06 2004 @@ -731,7 +731,7 @@ int inet_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int size, int flags) + size_t size, int flags) { struct sock *sk = sock->sk; int addr_len = 0; @@ -746,7 +746,7 @@ int inet_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int size) + size_t size) { struct sock *sk = sock->sk; diff -Nru a/net/ipv4/raw.c b/net/ipv4/raw.c --- a/net/ipv4/raw.c Fri Jan 9 13:38:06 2004 +++ b/net/ipv4/raw.c Fri Jan 9 13:38:06 2004 @@ -324,7 +324,7 @@ } static int raw_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, - int len) + size_t len) { struct inet_opt *inet = inet_sk(sk); struct ipcm_cookie ipc; @@ -335,17 +335,6 @@ u8 tos; int err; - /* This check is ONLY to check for arithmetic overflow - on integer(!) len. Not more! Real check will be made - in ip_build_xmit --ANK - - BTW socket.c -> af_*.c -> ... make multiple - invalid conversions size_t -> int. We MUST repair it f.e. - by replacing all of them with size_t and revise all - the places sort of len += sizeof(struct iphdr) - If len was ULONG_MAX-10 it would be cathastrophe --ANK - */ - err = -EMSGSIZE; if (len < 0 || len > 0xFFFF) goto out; @@ -523,10 +512,10 @@ */ int raw_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, - int len, int noblock, int flags, int *addr_len) + size_t len, int noblock, int flags, int *addr_len) { struct inet_opt *inet = inet_sk(sk); - int copied = 0; + size_t copied = 0; int err = -EOPNOTSUPP; struct sockaddr_in *sin = (struct sockaddr_in *)msg->msg_name; struct sk_buff *skb; diff -Nru a/net/ipv4/tcp.c b/net/ipv4/tcp.c --- a/net/ipv4/tcp.c Fri Jan 9 13:38:06 2004 +++ b/net/ipv4/tcp.c Fri Jan 9 13:38:06 2004 @@ -1029,7 +1029,7 @@ } int tcp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, - int size) + size_t size) { struct iovec *iov; struct tcp_opt *tp = tcp_sk(sk); @@ -1498,7 +1498,7 @@ */ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, - int len, int nonblock, int flags, int *addr_len) + size_t len, int nonblock, int flags, int *addr_len) { struct tcp_opt *tp = tcp_sk(sk); int copied = 0; diff -Nru a/net/ipv4/udp.c b/net/ipv4/udp.c --- a/net/ipv4/udp.c Fri Jan 9 13:38:06 2004 +++ b/net/ipv4/udp.c Fri Jan 9 13:38:06 2004 @@ -478,7 +478,7 @@ } int udp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, - int len) + size_t len) { struct inet_opt *inet = inet_sk(sk); struct udp_opt *up = udp_sk(sk); @@ -493,18 +493,7 @@ int err; int corkreq = up->corkflag || msg->msg_flags&MSG_MORE; - /* This check is ONLY to check for arithmetic overflow - on integer(!) len. Not more! Real check will be made - in ip_append_* --ANK - - BTW socket.c -> af_*.c -> ... make multiple - invalid conversions size_t -> int. We MUST repair it f.e. - by replacing all of them with size_t and revise all - the places sort of len += sizeof(struct iphdr) - If len was ULONG_MAX-10 it would be cathastrophe --ANK - */ - - if (len < 0 || len > 0xFFFF) + if (len > 0xFFFF) return -EMSGSIZE; /* @@ -782,7 +771,7 @@ */ int udp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, - int len, int noblock, int flags, int *addr_len) + size_t len, int noblock, int flags, int *addr_len) { struct inet_opt *inet = inet_sk(sk); struct sockaddr_in *sin = (struct sockaddr_in *)msg->msg_name; diff -Nru a/net/ipv6/raw.c b/net/ipv6/raw.c --- a/net/ipv6/raw.c Fri Jan 9 13:38:06 2004 +++ b/net/ipv6/raw.c Fri Jan 9 13:38:06 2004 @@ -345,13 +345,15 @@ * we return it, otherwise we block. */ -static int rawv6_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, int len, +static int rawv6_recvmsg(struct kiocb *iocb, struct sock *sk, + struct msghdr *msg, size_t len, int noblock, int flags, int *addr_len) { struct ipv6_pinfo *np = inet6_sk(sk); struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *)msg->msg_name; struct sk_buff *skb; - int copied, err; + size_t copied; + int err; if (flags & MSG_OOB) return -EOPNOTSUPP; @@ -527,7 +529,8 @@ IP6_INC_STATS(Ip6OutDiscards); return err; } -static int rawv6_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, int len) +static int rawv6_sendmsg(struct kiocb *iocb, struct sock *sk, + struct msghdr *msg, size_t len) { struct ipv6_txoptions opt_space; struct sockaddr_in6 * sin6 = (struct sockaddr_in6 *) msg->msg_name; diff -Nru a/net/ipv6/udp.c b/net/ipv6/udp.c --- a/net/ipv6/udp.c Fri Jan 9 13:38:06 2004 +++ b/net/ipv6/udp.c Fri Jan 9 13:38:06 2004 @@ -366,12 +366,14 @@ * return it, otherwise we block. */ -static int udpv6_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, int len, +static int udpv6_recvmsg(struct kiocb *iocb, struct sock *sk, + struct msghdr *msg, size_t len, int noblock, int flags, int *addr_len) { struct ipv6_pinfo *np = inet6_sk(sk); struct sk_buff *skb; - int copied, err; + size_t copied; + int err; if (addr_len) *addr_len=sizeof(struct sockaddr_in6); @@ -774,7 +776,8 @@ return err; } -static int udpv6_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, int len) +static int udpv6_sendmsg(struct kiocb *iocb, struct sock *sk, + struct msghdr *msg, size_t len) { struct ipv6_txoptions opt_space; struct udp_opt *up = udp_sk(sk); @@ -841,7 +844,7 @@ /* Rough check on arithmetic overflow, better check is made in ip6_build_xmit */ - if (len < 0 || len > INT_MAX - sizeof(struct udphdr)) + if (len > INT_MAX - sizeof(struct udphdr)) return -EMSGSIZE; if (up->pending) { diff -Nru a/net/sctp/socket.c b/net/sctp/socket.c --- a/net/sctp/socket.c Fri Jan 9 13:38:06 2004 +++ b/net/sctp/socket.c Fri Jan 9 13:38:06 2004 @@ -90,7 +90,7 @@ static inline void sctp_set_owner_w(struct sctp_chunk *chunk); static void sctp_wfree(struct sk_buff *skb); static int sctp_wait_for_sndbuf(struct sctp_association *, long *timeo_p, - int msg_len); + size_t msg_len); static int sctp_wait_for_packet(struct sock * sk, int *err, long *timeo_p); static int sctp_wait_for_connect(struct sctp_association *, long *timeo_p); static int sctp_wait_for_accept(struct sock *sk, long timeo); @@ -943,7 +943,7 @@ SCTP_STATIC int sctp_msghdr_parse(const struct msghdr *, sctp_cmsgs_t *); SCTP_STATIC int sctp_sendmsg(struct kiocb *iocb, struct sock *sk, - struct msghdr *msg, int msg_len) + struct msghdr *msg, size_t msg_len) { struct sctp_opt *sp; struct sctp_endpoint *ep; @@ -965,7 +965,7 @@ struct list_head *pos; int msg_flags = msg->msg_flags; - SCTP_DEBUG_PRINTK("sctp_sendmsg(sk: %p, msg: %p, msg_len: %d)\n", + SCTP_DEBUG_PRINTK("sctp_sendmsg(sk: %p, msg: %p, msg_len: %u)\n", sk, msg, msg_len); err = 0; @@ -1021,7 +1021,7 @@ associd = sinfo->sinfo_assoc_id; } - SCTP_DEBUG_PRINTK("msg_len: %d, sinfo_flags: 0x%x\n", + SCTP_DEBUG_PRINTK("msg_len: %u, sinfo_flags: 0x%x\n", msg_len, sinfo_flags); /* MSG_EOF or MSG_ABORT cannot be set on a TCP-style socket. */ @@ -1377,7 +1377,7 @@ static struct sk_buff *sctp_skb_recv_datagram(struct sock *, int, int, int *); SCTP_STATIC int sctp_recvmsg(struct kiocb *iocb, struct sock *sk, - struct msghdr *msg, int len, int noblock, + struct msghdr *msg, size_t len, int noblock, int flags, int *addr_len) { struct sctp_ulpevent *event = NULL; @@ -4157,14 +4157,14 @@ /* Helper function to wait for space in the sndbuf. */ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p, - int msg_len) + size_t msg_len) { struct sock *sk = asoc->base.sk; int err = 0; long current_timeo = *timeo_p; DEFINE_WAIT(wait); - SCTP_DEBUG_PRINTK("wait_for_sndbuf: asoc=%p, timeo=%ld, msg_len=%d\n", + SCTP_DEBUG_PRINTK("wait_for_sndbuf: asoc=%p, timeo=%ld, msg_len=%u\n", asoc, (long)(*timeo_p), msg_len); /* Increment the association's refcnt. */ From shemminger@osdl.org Thu Jan 8 13:39:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 13:39:26 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LdCTa028018 for ; Thu, 8 Jan 2004 13:39:12 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08Ld0o03884; Thu, 8 Jan 2004 13:39:00 -0800 Date: Fri, 9 Jan 2004 13:26:58 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (1/17) protocol sendmsg/revmsg prototype Message-Id: <20040109132658.01aa28dd@linux.local> X-Mailer: Sylpheed version 0.9.8claws (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: 2285 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 Content-Length: 6285 Lines: 156 When sendmsg (or recvmsg) system call is processed, the total size of the message is calculated as unsigned (size_t), but then passed through as integer in the protocol switch table. This leads to possible problems when protocols only check size > pmtu and size could potentially be negative. The protocols work around this (mostly) today by checking for less than zero or recasting, but the right thing is to change protocol switch to pass it through as size_t. This doesn't change the user ABI for sendmsg/recvmsg. The first patch changes the prototype, and causes all the protocols to generate warnings that are cleared up in the next sixteen. This was found by Chris Wright who raised it a potential DOS attack point. diff -Nru a/include/linux/net.h b/include/linux/net.h --- a/include/linux/net.h Mon Dec 8 16:19:31 2003 +++ b/include/linux/net.h Mon Dec 8 16:19:31 2003 @@ -120,9 +120,9 @@ int (*getsockopt)(struct socket *sock, int level, int optname, char __user *optval, int __user *optlen); int (*sendmsg) (struct kiocb *iocb, struct socket *sock, - struct msghdr *m, int total_len); + struct msghdr *m, size_t total_len); int (*recvmsg) (struct kiocb *iocb, struct socket *sock, - struct msghdr *m, int total_len, + struct msghdr *m, size_t total_len, int flags); int (*mmap) (struct file *file, struct socket *sock, struct vm_area_struct * vma); @@ -151,13 +151,13 @@ struct socket **res); extern void sock_release(struct socket *sock); extern int sock_sendmsg(struct socket *sock, struct msghdr *msg, - int len); + size_t len); extern int sock_recvmsg(struct socket *sock, struct msghdr *msg, - int size, int flags); + size_t size, int flags); extern int sock_readv_writev(int type, struct inode *inode, struct file *file, const struct iovec *iov, long count, - long size); + size_t size); extern int sock_map_fd(struct socket *sock); extern struct socket *sockfd_lookup(int fd, int *err); #define sockfd_put(sock) fput(sock->file) @@ -216,9 +216,9 @@ char *optval, int optlen), (sock, level, optname, optval, optlen)) \ SOCKCALL_WRAP(name, getsockopt, (struct socket *sock, int level, int optname, \ char *optval, int *optlen), (sock, level, optname, optval, optlen)) \ -SOCKCALL_WRAP(name, sendmsg, (struct kiocb *iocb, struct socket *sock, struct msghdr *m, int len), \ +SOCKCALL_WRAP(name, sendmsg, (struct kiocb *iocb, struct socket *sock, struct msghdr *m, size_t len), \ (iocb, sock, m, len)) \ -SOCKCALL_WRAP(name, recvmsg, (struct kiocb *iocb, struct socket *sock, struct msghdr *m, int len, int flags), \ +SOCKCALL_WRAP(name, recvmsg, (struct kiocb *iocb, struct socket *sock, struct msghdr *m, size_t len, int flags), \ (iocb, sock, m, len, flags)) \ SOCKCALL_WRAP(name, mmap, (struct file *file, struct socket *sock, struct vm_area_struct *vma), \ (file, sock, vma)) \ diff -Nru a/include/net/sock.h b/include/net/sock.h --- a/include/net/sock.h Mon Dec 8 16:19:31 2003 +++ b/include/net/sock.h Mon Dec 8 16:19:31 2003 @@ -418,10 +418,10 @@ int optname, char *optval, int *option); int (*sendmsg)(struct kiocb *iocb, struct sock *sk, - struct msghdr *msg, int len); + struct msghdr *msg, size_t len); int (*recvmsg)(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, - int len, int noblock, int flags, + size_t len, int noblock, int flags, int *addr_len); int (*sendpage)(struct sock *sk, struct page *page, int offset, size_t size, int flags); @@ -624,9 +624,9 @@ extern int sock_no_setsockopt(struct socket *, int, int, char *, int); extern int sock_no_sendmsg(struct kiocb *, struct socket *, - struct msghdr *, int); + struct msghdr *, size_t); extern int sock_no_recvmsg(struct kiocb *, struct socket *, - struct msghdr *, int, int); + struct msghdr *, size_t, int); extern int sock_no_mmap(struct file *file, struct socket *sock, struct vm_area_struct *vma); diff -Nru a/net/core/sock.c b/net/core/sock.c --- a/net/core/sock.c Mon Dec 8 16:19:31 2003 +++ b/net/core/sock.c Mon Dec 8 16:19:31 2003 @@ -966,13 +966,13 @@ } int sock_no_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, - int flags) + size_t len) { return -EOPNOTSUPP; } int sock_no_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, - int len, int flags) + size_t len, int flags) { return -EOPNOTSUPP; } diff -Nru a/net/socket.c b/net/socket.c --- a/net/socket.c Mon Dec 8 16:19:31 2003 +++ b/net/socket.c Mon Dec 8 16:19:31 2003 @@ -523,7 +523,8 @@ sock->file=NULL; } -static inline int __sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int size) +static inline int __sock_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, size_t size) { struct sock_iocb *si = kiocb_to_siocb(iocb); int err; @@ -540,7 +541,7 @@ return sock->ops->sendmsg(iocb, sock, msg, size); } -int sock_sendmsg(struct socket *sock, struct msghdr *msg, int size) +int sock_sendmsg(struct socket *sock, struct msghdr *msg, size_t size) { struct kiocb iocb; int ret; @@ -553,7 +554,8 @@ } -static inline int __sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int size, int flags) +static inline int __sock_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, size_t size, int flags) { int err; struct sock_iocb *si = kiocb_to_siocb(iocb); @@ -571,7 +573,8 @@ return sock->ops->recvmsg(iocb, sock, msg, size, flags); } -int sock_recvmsg(struct socket *sock, struct msghdr *msg, int size, int flags) +int sock_recvmsg(struct socket *sock, struct msghdr *msg, + size_t size, int flags) { struct kiocb iocb; int ret; @@ -668,7 +671,7 @@ } int sock_readv_writev(int type, struct inode * inode, struct file * file, - const struct iovec * iov, long count, long size) + const struct iovec * iov, long count, size_t size) { struct msghdr msg; struct socket *sock; From shemminger@osdl.org Thu Jan 8 13:39:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 13:39:27 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LdDTa028020 for ; Thu, 8 Jan 2004 13:39:13 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08Ld1o03902; Thu, 8 Jan 2004 13:39:01 -0800 Date: Fri, 9 Jan 2004 13:40:00 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, Maxim Krasnyansky Subject: [PATCH] (3/17) bluetooth -- size_t for send/recvmsg Message-Id: <20040109134000.7201c3af@linux.local> X-Mailer: Sylpheed version 0.9.8claws (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: 2287 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 Content-Length: 4695 Lines: 136 Convert bluetooth sendmsg/recvmsg from size as int to size_t. Add check in HCI that sendmsg < max allowed frame size. diff -Nru a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h --- a/include/net/bluetooth/bluetooth.h Mon Dec 8 16:19:37 2003 +++ b/include/net/bluetooth/bluetooth.h Mon Dec 8 16:19:37 2003 @@ -129,7 +129,7 @@ struct sock *bt_sock_alloc(struct socket *sock, int proto, int pi_size, int prio); void bt_sock_link(struct bt_sock_list *l, struct sock *s); void bt_sock_unlink(struct bt_sock_list *l, struct sock *s); -int bt_sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len, int flags); +int bt_sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, size_t len, int flags); uint bt_sock_poll(struct file * file, struct socket *sock, poll_table *wait); int bt_sock_wait_state(struct sock *sk, int state, unsigned long timeo); diff -Nru a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c --- a/net/bluetooth/af_bluetooth.c Mon Dec 8 16:19:37 2003 +++ b/net/bluetooth/af_bluetooth.c Mon Dec 8 16:19:37 2003 @@ -201,12 +201,13 @@ } int bt_sock_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, int flags) + struct msghdr *msg, size_t len, int flags) { int noblock = flags & MSG_DONTWAIT; struct sock *sk = sock->sk; struct sk_buff *skb; - int copied, err; + size_t copied; + int err; BT_DBG("sock %p sk %p len %d", sock, sk, len); diff -Nru a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c --- a/net/bluetooth/hci_sock.c Mon Dec 8 16:19:37 2003 +++ b/net/bluetooth/hci_sock.c Mon Dec 8 16:19:37 2003 @@ -319,7 +319,8 @@ put_cmsg(msg, SOL_HCI, HCI_CMSG_TSTAMP, sizeof(skb->stamp), &skb->stamp); } -static int hci_sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len, int flags) +static int hci_sock_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, size_t len, int flags) { int noblock = flags & MSG_DONTWAIT; struct sock *sk = sock->sk; @@ -355,7 +356,8 @@ return err ? : copied; } -static int hci_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len) +static int hci_sock_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct hci_dev *hdev; @@ -370,9 +372,9 @@ if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_NOSIGNAL|MSG_ERRQUEUE)) return -EINVAL; - if (len < 4) + if (len < 4 || len > HCI_MAX_FRAME_SIZE) return -EINVAL; - + lock_sock(sk); if (!(hdev = hci_pi(sk)->hdev)) { diff -Nru a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c --- a/net/bluetooth/l2cap.c Mon Dec 8 16:19:37 2003 +++ b/net/bluetooth/l2cap.c Mon Dec 8 16:19:37 2003 @@ -706,7 +706,8 @@ return err; } -static int l2cap_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len) +static int l2cap_sock_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; int err = 0; diff -Nru a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c --- a/net/bluetooth/rfcomm/sock.c Mon Dec 8 16:19:37 2003 +++ b/net/bluetooth/rfcomm/sock.c Mon Dec 8 16:19:37 2003 @@ -482,12 +482,12 @@ } static int rfcomm_sock_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct rfcomm_dlc *d = rfcomm_pi(sk)->dlc; struct sk_buff *skb; - int err, size; + int err; int sent = 0; if (msg->msg_flags & MSG_OOB) @@ -501,7 +501,7 @@ lock_sock(sk); while (len) { - size = min_t(uint, len, d->mtu); + size_t size = min(len, d->mtu); skb = sock_alloc_send_skb(sk, size + RFCOMM_SKB_RESERVE, msg->msg_flags & MSG_DONTWAIT, &err); @@ -556,10 +556,11 @@ } static int rfcomm_sock_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags) + struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; - int target, err = 0, copied = 0; + int err = 0; + size_t target, copied = 0; long timeo; if (flags & MSG_OOB) diff -Nru a/net/bluetooth/sco.c b/net/bluetooth/sco.c --- a/net/bluetooth/sco.c Mon Dec 8 16:19:37 2003 +++ b/net/bluetooth/sco.c Mon Dec 8 16:19:37 2003 @@ -630,7 +630,8 @@ return 0; } -static int sco_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len) +static int sco_sock_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; int err = 0; From shemminger@osdl.org Thu Jan 8 13:41:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 13:41:33 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LfJTa029044 for ; Thu, 8 Jan 2004 13:41:19 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08Lf8o04216; Thu, 8 Jan 2004 13:41:08 -0800 Date: Fri, 9 Jan 2004 13:42:15 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, Michal Ostrowski Subject: [PATCH] (4/17) pppoe -- size_t in send/recvmsg Message-Id: <20040109134215.14fbcf8a@linux.local> X-Mailer: Sylpheed version 0.9.8claws (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: 2288 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 Content-Length: 760 Lines: 25 Convert PPPoe for size_t in send/recv msg diff -Nru a/drivers/net/pppoe.c b/drivers/net/pppoe.c --- a/drivers/net/pppoe.c Mon Dec 8 16:19:40 2003 +++ b/drivers/net/pppoe.c Mon Dec 8 16:19:40 2003 @@ -775,8 +775,8 @@ } -static int pppoe_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, - int total_len) +static int pppoe_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *m, size_t total_len) { struct sk_buff *skb = NULL; struct sock *sk = sock->sk; @@ -939,7 +939,7 @@ }; static int pppoe_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *m, int total_len, int flags) + struct msghdr *m, size_t total_len, int flags) { struct sock *sk = sock->sk; struct sk_buff *skb = NULL; From shemminger@osdl.org Thu Jan 8 13:43:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 13:43:53 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LheTa029410 for ; Thu, 8 Jan 2004 13:43:40 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08LhSo04595; Thu, 8 Jan 2004 13:43:29 -0800 Date: Fri, 9 Jan 2004 13:44:36 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, acme@conectiva.com.br Subject: [PATCH] (5/17) ddp -- size_t for send/recvmsg Message-Id: <20040109134436.6aa8fe1f@linux.local> X-Mailer: Sylpheed version 0.9.8claws (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: 2289 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 Content-Length: 695 Lines: 23 Change send/recvmsg to match prototype change in sock.h diff -Nru a/net/appletalk/ddp.c b/net/appletalk/ddp.c --- a/net/appletalk/ddp.c Mon Dec 8 16:19:43 2003 +++ b/net/appletalk/ddp.c Mon Dec 8 16:19:43 2003 @@ -1552,7 +1552,7 @@ } static int atalk_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int len) + size_t len) { struct sock *sk = sock->sk; struct atalk_sock *at = at_sk(sk); @@ -1712,7 +1712,7 @@ } static int atalk_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int size, int flags) + size_t size, int flags) { struct sock *sk = sock->sk; struct sockaddr_at *sat = (struct sockaddr_at *)msg->msg_name; From shemminger@osdl.org Thu Jan 8 13:47:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 13:47:42 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LlSTa029857 for ; Thu, 8 Jan 2004 13:47:28 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08Ll5o05168; Thu, 8 Jan 2004 13:47:05 -0800 Date: Fri, 9 Jan 2004 13:48:12 -0800 From: Stephen Hemminger To: "David S. Miller" , Chas Williams Cc: netdev@oss.sgi.com Subject: [PATCH[ (6/15) atm -- size_t in send/recvmsg Message-Id: <20040109134812.6fa874c8@linux.local> X-Mailer: Sylpheed version 0.9.8claws (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: 2291 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 Content-Length: 1368 Lines: 38 Convert ATM for unsigned length send/recvmsg to match new prototype. diff -Nru a/net/atm/common.c b/net/atm/common.c --- a/net/atm/common.c Mon Dec 8 16:19:46 2003 +++ b/net/atm/common.c Mon Dec 8 16:19:46 2003 @@ -463,7 +463,7 @@ int vcc_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int size, int flags) + size_t size, int flags) { struct sock *sk = sock->sk; struct atm_vcc *vcc; @@ -503,7 +503,7 @@ int vcc_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, - int total_len) + size_t total_len) { struct sock *sk = sock->sk; DEFINE_WAIT(wait); diff -Nru a/net/atm/common.h b/net/atm/common.h --- a/net/atm/common.h Mon Dec 8 16:19:46 2003 +++ b/net/atm/common.h Mon Dec 8 16:19:46 2003 @@ -14,9 +14,9 @@ int vcc_release(struct socket *sock); int vcc_connect(struct socket *sock, int itf, short vpi, int vci); int vcc_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int size, int flags); + size_t size, int flags); int vcc_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, - int total_len); + size_t total_len); unsigned int vcc_poll(struct file *file, struct socket *sock, poll_table *wait); int vcc_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg); int vcc_setsockopt(struct socket *sock, int level, int optname, char *optval, From shemminger@osdl.org Thu Jan 8 13:47:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 13:47:40 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LlQTa029854 for ; Thu, 8 Jan 2004 13:47:27 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08Ll8o05200; Thu, 8 Jan 2004 13:47:08 -0800 Date: Fri, 9 Jan 2004 13:48:15 -0800 From: Stephen Hemminger To: "David S. Miller" , Ralf Baechle Cc: netdev@oss.sgi.com Subject: [PATCH] (7/15) ax25 - size_t in send/recvmsg Message-Id: <20040109134815.09ef4df0@linux.local> X-Mailer: Sylpheed version 0.9.8claws (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: 2290 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 Content-Length: 1254 Lines: 46 Convert Amateur Radio X.25 to unsigned size for send/receive. Also enforce an MTU here, since there is no fragmentation logic. diff -Nru a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c --- a/net/ax25/af_ax25.c Mon Dec 8 16:19:49 2003 +++ b/net/ax25/af_ax25.c Mon Dec 8 16:19:49 2003 @@ -1415,7 +1415,7 @@ } static int ax25_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sockaddr_ax25 *usax = (struct sockaddr_ax25 *)msg->msg_name; struct sock *sk = sock->sk; @@ -1424,7 +1424,8 @@ ax25_digi dtmp, *dp; unsigned char *asmptr; ax25_cb *ax25; - int lv, size, err, addr_len = msg->msg_namelen; + size_t size; + int lv, err, addr_len = msg->msg_namelen; if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR)) { return -EINVAL; @@ -1449,6 +1450,11 @@ goto out; } + if (len > ax25->ax25_dev->dev->mtu) { + err = -EMSGSIZE; + goto out; + } + if (usax != NULL) { if (usax->sax25_family != AF_AX25) { err = -EINVAL; @@ -1594,7 +1600,7 @@ } static int ax25_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags) + struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; struct sk_buff *skb; From acme@conectiva.com.br Thu Jan 8 13:54:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 13:55:01 -0800 (PST) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LslTa031032 for ; Thu, 8 Jan 2004 13:54:48 -0800 Received: from 4-203.ctame700-6.telepar.net.br ([200.140.237.203] helo=oops.kerneljanitors.org) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1AeiEN-0000eu-00; Thu, 08 Jan 2004 20:02:20 -0200 Received: by oops.kerneljanitors.org (Postfix, from userid 500) id B6C191966D; Thu, 8 Jan 2004 20:05:30 -0200 (BRDT) Date: Thu, 8 Jan 2004 20:05:30 -0200 From: Arnaldo Carvalho de Melo To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] (5/17) ddp -- size_t for send/recvmsg Message-ID: <20040108220530.GB3062@conectiva.com.br> References: <20040109134436.6aa8fe1f@linux.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040109134436.6aa8fe1f@linux.local> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.5.1i X-archive-position: 2292 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 363 Lines: 11 Em Fri, Jan 09, 2004 at 01:44:36PM -0800, Stephen Hemminger escreveu: > Change send/recvmsg to match prototype change in sock.h > > diff -Nru a/net/appletalk/ddp.c b/net/appletalk/ddp.c > --- a/net/appletalk/ddp.c Mon Dec 8 16:19:43 2003 > +++ b/net/appletalk/ddp.c Mon Dec 8 16:19:43 2003 > @@ -1552,7 +1552,7 @@ I'm OK with this, thanks Stephen. - Arnaldo From shemminger@osdl.org Thu Jan 8 14:02:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:03:10 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M2uTa031576 for ; Thu, 8 Jan 2004 14:02:56 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08M2fo08259; Thu, 8 Jan 2004 14:02:41 -0800 Date: Fri, 9 Jan 2004 14:03:11 -0800 From: Stephen Hemminger To: "David S. Miller" , acme@conectiva.com.br Cc: netdev@oss.sgi.com Subject: [PATCH] (13/17) llc -- size_t for send/recvmsg Message-Id: <20040109140311.66c2fa57@linux.local> X-Mailer: Sylpheed version 0.9.8claws (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: 2300 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 Content-Length: 1365 Lines: 40 Convert LLC to unsigned for send/recv msg. diff -Nru a/net/llc/af_llc.c b/net/llc/af_llc.c --- a/net/llc/af_llc.c Mon Dec 8 16:20:07 2003 +++ b/net/llc/af_llc.c Mon Dec 8 16:20:07 2003 @@ -671,12 +671,13 @@ * Returns non-negative upon success, negative otherwise. */ static int llc_ui_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags) + struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; struct sockaddr_llc *uaddr = (struct sockaddr_llc *)msg->msg_name; struct sk_buff *skb; - int rc = -ENOMEM, copied = 0, timeout; + size_t copied = 0; + int rc = -ENOMEM, timeout; int noblock = flags & MSG_DONTWAIT; dprintk("%s: receiving in %02X from %02X\n", __FUNCTION__, @@ -725,7 +726,7 @@ * Returns non-negative upon success, negative otherwise. */ static int llc_ui_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct llc_opt *llc = llc_sk(sk); @@ -734,7 +735,8 @@ int noblock = flags & MSG_DONTWAIT; struct net_device *dev; struct sk_buff *skb; - int rc = -EINVAL, size = 0, copied = 0, hdrlen; + size_t size = 0; + int rc = -EINVAL, copied = 0, hdrlen; dprintk("%s: sending from %02X to %02X\n", __FUNCTION__, llc->laddr.lsap, llc->daddr.lsap); From shemminger@osdl.org Thu Jan 8 14:02:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:03:10 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M2sTa031570 for ; Thu, 8 Jan 2004 14:02:54 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08M2fo08239; Thu, 8 Jan 2004 14:02:41 -0800 Date: Fri, 9 Jan 2004 14:02:58 -0800 From: Stephen Hemminger To: "David S. Miller" , Ralf Baechle Cc: netdev@oss.sgi.com Subject: [PATCH] (14/17) netrom -- size_t for send/recvmsg Message-Id: <20040109140258.34aa7c73@linux.local> X-Mailer: Sylpheed version 0.9.8claws (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: 2299 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 Content-Length: 817 Lines: 28 Convert Netrom to unsigned length for send/receive msg. diff -Nru a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c --- a/net/netrom/af_netrom.c Mon Dec 8 16:20:10 2003 +++ b/net/netrom/af_netrom.c Mon Dec 8 16:20:10 2003 @@ -1003,7 +1003,7 @@ } static int nr_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; nr_cb *nr = nr_sk(sk); @@ -1112,11 +1112,11 @@ } static int nr_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags) + struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; struct sockaddr_ax25 *sax = (struct sockaddr_ax25 *)msg->msg_name; - int copied; + size_t copied; struct sk_buff *skb; int er; From shemminger@osdl.org Thu Jan 8 14:02:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:03:08 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M2pTa031564 for ; Thu, 8 Jan 2004 14:02:51 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08M2bo08194; Thu, 8 Jan 2004 14:02:37 -0800 Date: Fri, 9 Jan 2004 14:03:36 -0800 From: Stephen Hemminger To: "David S. Miller" , Steven Whitehouse Cc: netdev@oss.sgi.com Subject: [PATCH] (9/17) decnet -- size_t in sned/recvmsg Message-Id: <20040109140336.45c393c5@linux.local> X-Mailer: Sylpheed version 0.9.8claws (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: 2297 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 Content-Length: 1582 Lines: 56 Send/recv msg now take an unsigned total message length. diff -Nru a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c --- a/net/decnet/af_decnet.c Mon Dec 8 16:19:55 2003 +++ b/net/decnet/af_decnet.c Mon Dec 8 16:19:55 2003 @@ -1659,13 +1659,13 @@ static int dn_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags) + struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; struct dn_scp *scp = DN_SK(sk); struct sk_buff_head *queue = &sk->sk_receive_queue; - int target = size > 1 ? 1 : 0; - int copied = 0; + size_t target = size > 1 ? 1 : 0; + size_t copied = 0; int rv = 0; struct sk_buff *skb, *nskb; struct dn_skb_cb *cb = NULL; @@ -1746,7 +1746,7 @@ } for(skb = queue->next; skb != (struct sk_buff *)queue; skb = nskb) { - int chunk = skb->len; + unsigned int chunk = skb->len; cb = DN_SKB_CB(skb); if ((chunk + copied) > size) @@ -1888,20 +1888,20 @@ } static int dn_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size) + struct msghdr *msg, size_t size) { struct sock *sk = sock->sk; struct dn_scp *scp = DN_SK(sk); - int mss; + size_t mss; struct sk_buff_head *queue = &scp->data_xmit_queue; int flags = msg->msg_flags; int err = 0; - int sent = 0; + size_t sent = 0; int addr_len = msg->msg_namelen; struct sockaddr_dn *addr = (struct sockaddr_dn *)msg->msg_name; struct sk_buff *skb = NULL; struct dn_skb_cb *cb; - int len; + size_t len; unsigned char fctype; long timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT); From shemminger@osdl.org Thu Jan 8 14:02:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:03:09 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M2sTa031571 for ; Thu, 8 Jan 2004 14:02:55 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08M2eo08231; Thu, 8 Jan 2004 14:02:40 -0800 Date: Fri, 9 Jan 2004 14:02:23 -0800 From: Stephen Hemminger To: "David S. Miller" , Arnaldo Carvalho de Melo Cc: netdev@oss.sgi.com Subject: [PATCH] (8/17) ipx -- size_t for send/recvmsg Message-Id: <20040109140223.3926cbeb@linux.local> X-Mailer: Sylpheed version 0.9.8claws (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: 2298 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 Content-Length: 1575 Lines: 54 Convert IPX to unsigned for send/receive message length. Enforce MTU limited by header pktsize. diff -Nru a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c --- a/net/ipx/af_ipx.c Mon Dec 8 16:19:52 2003 +++ b/net/ipx/af_ipx.c Mon Dec 8 16:19:52 2003 @@ -1683,7 +1683,7 @@ } static int ipx_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct ipx_opt *ipxs = ipx_sk(sk); @@ -1698,6 +1698,10 @@ if (flags & ~MSG_DONTWAIT) goto out; + /* Max possible packet size limited by 16 bit pktsize in header */ + if (len >= 65535 - sizeof(struct ipxhdr)) + goto out; + if (usipx) { if (!ipxs->port) { struct sockaddr_ipx uaddr; @@ -1744,7 +1748,7 @@ static int ipx_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags) + struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; struct ipx_opt *ipxs = ipx_sk(sk); diff -Nru a/net/ipx/ipx_route.c b/net/ipx/ipx_route.c --- a/net/ipx/ipx_route.c Mon Dec 8 16:19:52 2003 +++ b/net/ipx/ipx_route.c Mon Dec 8 16:19:52 2003 @@ -169,13 +169,13 @@ * Route an outgoing frame from a socket. */ int ipxrtr_route_packet(struct sock *sk, struct sockaddr_ipx *usipx, - struct iovec *iov, int len, int noblock) + struct iovec *iov, size_t len, int noblock) { struct sk_buff *skb; struct ipx_opt *ipxs = ipx_sk(sk); struct ipx_interface *intrfc; struct ipxhdr *ipx; - int size; + size_t size; int ipx_offset; struct ipx_route *rt = NULL; int rc; From shemminger@osdl.org Thu Jan 8 14:02:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:03:08 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M2qTa031565 for ; Thu, 8 Jan 2004 14:02:52 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08M2eo08235; Thu, 8 Jan 2004 14:02:40 -0800 Date: Fri, 9 Jan 2004 14:02:36 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (10/17) netlink/packet -- size_t for send/recvmsg Message-Id: <20040109140236.35fb993a@linux.local> X-Mailer: Sylpheed version 0.9.8claws (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: 2296 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 Content-Length: 2752 Lines: 93 Convert "maintance protocols" af_key, packet, netlink over to use unsigned length for send/receive message. diff -Nru a/net/key/af_key.c b/net/key/af_key.c --- a/net/key/af_key.c Mon Dec 8 16:19:58 2003 +++ b/net/key/af_key.c Mon Dec 8 16:19:58 2003 @@ -2655,7 +2655,7 @@ } static int pfkey_sendmsg(struct kiocb *kiocb, - struct socket *sock, struct msghdr *msg, int len) + struct socket *sock, struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct sk_buff *skb = NULL; @@ -2697,7 +2697,7 @@ } static int pfkey_recvmsg(struct kiocb *kiocb, - struct socket *sock, struct msghdr *msg, int len, + struct socket *sock, struct msghdr *msg, size_t len, int flags) { struct sock *sk = sock->sk; diff -Nru a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c --- a/net/netlink/af_netlink.c Mon Dec 8 16:19:58 2003 +++ b/net/netlink/af_netlink.c Mon Dec 8 16:19:58 2003 @@ -601,7 +601,7 @@ } static int netlink_sendmsg(struct kiocb *kiocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock_iocb *siocb = kiocb_to_siocb(kiocb); struct sock *sk = sock->sk; @@ -641,7 +641,7 @@ } err = -EMSGSIZE; - if ((unsigned)len > sk->sk_sndbuf - 32) + if (len > sk->sk_sndbuf - 32) goto out; err = -ENOBUFS; skb = alloc_skb(len, GFP_KERNEL); @@ -683,7 +683,7 @@ } static int netlink_recvmsg(struct kiocb *kiocb, struct socket *sock, - struct msghdr *msg, int len, + struct msghdr *msg, size_t len, int flags) { struct sock_iocb *siocb = kiocb_to_siocb(kiocb); @@ -691,7 +691,7 @@ struct sock *sk = sock->sk; struct netlink_opt *nlk = nlk_sk(sk); int noblock = flags&MSG_DONTWAIT; - int copied; + size_t copied; struct sk_buff *skb; int err; diff -Nru a/net/packet/af_packet.c b/net/packet/af_packet.c --- a/net/packet/af_packet.c Mon Dec 8 16:19:58 2003 +++ b/net/packet/af_packet.c Mon Dec 8 16:19:58 2003 @@ -279,7 +279,7 @@ */ static int packet_sendmsg_spkt(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct sockaddr_pkt *saddr=(struct sockaddr_pkt *)msg->msg_name; @@ -651,7 +651,7 @@ static int packet_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct sockaddr_ll *saddr=(struct sockaddr_ll *)msg->msg_name; @@ -999,7 +999,7 @@ */ static int packet_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, int flags) + struct msghdr *msg, size_t len, int flags) { struct sock *sk = sock->sk; struct sk_buff *skb; From shemminger@osdl.org Thu Jan 8 14:02:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:03:06 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M2oTa031562 for ; Thu, 8 Jan 2004 14:02:50 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08M2do08223; Thu, 8 Jan 2004 14:02:39 -0800 Date: Fri, 9 Jan 2004 14:01:16 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (16/17) af_unix -- size_t for send/recvmsg Message-Id: <20040109140116.639569b6@linux.local> X-Mailer: Sylpheed version 0.9.8claws (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: 2294 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 Content-Length: 1490 Lines: 50 Convert Unix domain to handle unsigned for length in send/recv msg. diff -Nru a/net/unix/af_unix.c b/net/unix/af_unix.c --- a/net/unix/af_unix.c Mon Dec 8 16:20:16 2003 +++ b/net/unix/af_unix.c Mon Dec 8 16:20:16 2003 @@ -1176,7 +1176,7 @@ */ static int unix_dgram_sendmsg(struct kiocb *kiocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock_iocb *siocb = kiocb_to_siocb(kiocb); struct sock *sk = sock->sk; @@ -1217,7 +1217,7 @@ goto out; err = -EMSGSIZE; - if ((unsigned)len > sk->sk_sndbuf - 32) + if (len > sk->sk_sndbuf - 32) goto out; skb = sock_alloc_send_skb(sk, len, msg->msg_flags&MSG_DONTWAIT, &err); @@ -1324,7 +1324,7 @@ static int unix_stream_sendmsg(struct kiocb *kiocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock_iocb *siocb = kiocb_to_siocb(kiocb); struct sock *sk = sock->sk; @@ -1447,7 +1447,7 @@ } static int unix_dgram_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, + struct msghdr *msg, size_t size, int flags) { struct sock_iocb *siocb = kiocb_to_siocb(iocb); @@ -1555,7 +1555,7 @@ static int unix_stream_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, + struct msghdr *msg, size_t size, int flags) { struct sock_iocb *siocb = kiocb_to_siocb(iocb); From shemminger@osdl.org Thu Jan 8 14:02:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:03:06 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M2oTa031563 for ; Thu, 8 Jan 2004 14:02:51 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08M2do08227; Thu, 8 Jan 2004 14:02:39 -0800 Date: Fri, 9 Jan 2004 14:02:08 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (17/17) x25 -- size_t for send/recvmsg Message-Id: <20040109140208.7dd9a0fe@linux.local> X-Mailer: Sylpheed version 0.9.8claws (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: 2295 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 Content-Length: 1170 Lines: 41 Convert X.25 to handle unsigned for len in send/receive msg. diff -Nru a/net/x25/af_x25.c b/net/x25/af_x25.c --- a/net/x25/af_x25.c Mon Dec 8 16:20:19 2003 +++ b/net/x25/af_x25.c Mon Dec 8 16:20:19 2003 @@ -910,7 +910,7 @@ } static int x25_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct x25_opt *x25 = x25_sk(sk); @@ -919,7 +919,8 @@ struct sk_buff *skb; unsigned char *asmptr; int noblock = msg->msg_flags & MSG_DONTWAIT; - int size, qbit = 0, rc = -EINVAL; + size_t size; + int qbit = 0, rc = -EINVAL; if (msg->msg_flags & ~(MSG_DONTWAIT | MSG_OOB | MSG_EOR)) goto out; @@ -1085,13 +1086,14 @@ static int x25_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, + struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; struct x25_opt *x25 = x25_sk(sk); struct sockaddr_x25 *sx25 = (struct sockaddr_x25 *)msg->msg_name; - int copied, qbit; + size_t copied; + int qbit; struct sk_buff *skb; unsigned char *asmptr; int rc = -ENOTCONN; From shemminger@osdl.org Thu Jan 8 14:02:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:03:05 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M2mTa031561 for ; Thu, 8 Jan 2004 14:02:48 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08M2bo08190; Thu, 8 Jan 2004 14:02:37 -0800 Date: Fri, 9 Jan 2004 14:03:23 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (11/17) econet -- size_t for send/recvmsg Message-Id: <20040109140323.7d48f9db@linux.local> X-Mailer: Sylpheed version 0.9.8claws (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: 2293 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 Content-Length: 1046 Lines: 40 Convert econet over to unsigned length for send/recv msg. Add a bounds check based on device mtu - header. diff -Nru a/net/econet/af_econet.c b/net/econet/af_econet.c --- a/net/econet/af_econet.c Mon Dec 8 16:20:01 2003 +++ b/net/econet/af_econet.c Mon Dec 8 16:20:01 2003 @@ -113,11 +113,12 @@ */ static int econet_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, int flags) + struct msghdr *msg, size_t len, int flags) { struct sock *sk = sock->sk; struct sk_buff *skb; - int copied, err; + size_t copied; + int err; msg->msg_namelen = sizeof(struct sockaddr_ec); @@ -246,7 +247,7 @@ */ static int econet_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct sockaddr_ec *saddr=(struct sockaddr_ec *)msg->msg_name; @@ -307,6 +308,9 @@ if (dev == NULL) return -ENETDOWN; } + + if (len + 15 > dev->mtu) + return -EMSGSIZE; if (dev->type == ARPHRD_ECONET) { From shemminger@osdl.org Thu Jan 8 14:03:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:03:49 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M3YTa031898 for ; Thu, 8 Jan 2004 14:03:35 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08M2ao08186; Thu, 8 Jan 2004 14:02:36 -0800 Date: Fri, 9 Jan 2004 14:03:17 -0800 From: Stephen Hemminger To: "David S. Miller" , Jean Tourrilhes Cc: netdev@oss.sgi.com Subject: [PATCH] (12/17) irda -- size_t for send/recvmsg Message-Id: <20040109140317.0a8a30a8@linux.local> X-Mailer: Sylpheed version 0.9.8claws (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: 2301 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 Content-Length: 1919 Lines: 63 Convert IRDA to unsigned length for send/recv msg. diff -Nru a/net/irda/af_irda.c b/net/irda/af_irda.c --- a/net/irda/af_irda.c Mon Dec 8 16:20:04 2003 +++ b/net/irda/af_irda.c Mon Dec 8 16:20:04 2003 @@ -1257,7 +1257,7 @@ * fragment the message if necessary */ static int irda_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct irda_sock *self; @@ -1329,12 +1329,13 @@ * after being read, regardless of how much the user actually read */ static int irda_recvmsg_dgram(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags) + struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; struct irda_sock *self = irda_sk(sk); struct sk_buff *skb; - int copied, err; + size_t copied; + int err; IRDA_DEBUG(4, "%s()\n", __FUNCTION__); @@ -1379,12 +1380,12 @@ * Function irda_recvmsg_stream (iocb, sock, msg, size, flags) */ static int irda_recvmsg_stream(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags) + struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; struct irda_sock *self = irda_sk(sk); int noblock = flags & MSG_DONTWAIT; - int copied = 0; + size_t copied = 0; int target = 1; DECLARE_WAITQUEUE(waitq, current); @@ -1505,7 +1506,7 @@ * */ static int irda_sendmsg_dgram(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct irda_sock *self; @@ -1571,7 +1572,7 @@ */ #ifdef CONFIG_IRDA_ULTRA static int irda_sendmsg_ultra(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct irda_sock *self; From acme@conectiva.com.br Thu Jan 8 14:07:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:07:15 -0800 (PST) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M70Ta002299 for ; Thu, 8 Jan 2004 14:07:01 -0800 Received: from 4-203.ctame700-6.telepar.net.br ([200.140.237.203] helo=oops.kerneljanitors.org) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1AeiQD-0000fI-00; Thu, 08 Jan 2004 20:14:34 -0200 Received: by oops.kerneljanitors.org (Postfix, from userid 500) id B0C1C1966D; Thu, 8 Jan 2004 20:17:51 -0200 (BRDT) Date: Thu, 8 Jan 2004 20:17:51 -0200 From: Arnaldo Carvalho de Melo To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] (8/17) ipx -- size_t for send/recvmsg Message-ID: <20040108221751.GC3062@conectiva.com.br> References: <20040109140223.3926cbeb@linux.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040109140223.3926cbeb@linux.local> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.5.1i X-archive-position: 2302 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 192 Lines: 5 Em Fri, Jan 09, 2004 at 02:02:23PM -0800, Stephen Hemminger escreveu: > Convert IPX to unsigned for send/receive message length. > Enforce MTU limited by header pktsize. ACK, thanks Stephen. From acme@conectiva.com.br Thu Jan 8 14:07:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:07:26 -0800 (PST) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M7CTa002307 for ; Thu, 8 Jan 2004 14:07:13 -0800 Received: from 4-203.ctame700-6.telepar.net.br ([200.140.237.203] helo=oops.kerneljanitors.org) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1AeiQQ-0000fO-00; Thu, 08 Jan 2004 20:14:46 -0200 Received: by oops.kerneljanitors.org (Postfix, from userid 500) id C9F1C1966D; Thu, 8 Jan 2004 20:18:04 -0200 (BRDT) Date: Thu, 8 Jan 2004 20:18:04 -0200 From: Arnaldo Carvalho de Melo To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] (13/17) llc -- size_t for send/recvmsg Message-ID: <20040108221804.GD3062@conectiva.com.br> References: <20040109140311.66c2fa57@linux.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040109140311.66c2fa57@linux.local> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.5.1i X-archive-position: 2303 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 138 Lines: 5 Em Fri, Jan 09, 2004 at 02:03:11PM -0800, Stephen Hemminger escreveu: > Convert LLC to unsigned for send/recv msg. ACK, thanks Stephen. From jt@bougret.hpl.hp.com Thu Jan 8 15:18:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 15:18:47 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08NIOTa005875 for ; Thu, 8 Jan 2004 15:18:24 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id 8317F1C0060D; Thu, 8 Jan 2004 14:56:57 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_28810+JAGae91741+JAGae92668)/8.9.3 HPLabs Timeshare Server) with ESMTP id OAA07537; Thu, 8 Jan 2004 14:56:57 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Aej5F-0005xQ-00; Thu, 08 Jan 2004 14:56:57 -0800 Date: Thu, 8 Jan 2004 14:56:57 -0800 To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] (12/17) irda -- size_t for send/recvmsg Message-ID: <20040108225657.GB22438@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040109140317.0a8a30a8@linux.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040109140317.0a8a30a8@linux.local> 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: 2304 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 Content-Length: 211 Lines: 7 On Fri, Jan 09, 2004 at 02:03:17PM -0800, Stephen Hemminger wrote: > Convert IRDA to unsigned length for send/recv msg. Ok, I've added that on my web page and will remind Dave if he doesn't pick it up. Jean From davem@pizda.ninka.net Thu Jan 8 15:44:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 15:44:36 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08NiNTa006702 for ; Thu, 8 Jan 2004 15:44:23 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id PAA03186; Thu, 8 Jan 2004 15:36:17 -0800 Date: Thu, 8 Jan 2004 15:36:17 -0800 From: "David S. Miller" To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] (12/17) irda -- size_t for send/recvmsg Message-Id: <20040108153617.58a75a75.davem@redhat.com> In-Reply-To: <20040108225657.GB22438@bougret.hpl.hp.com> References: <20040109140317.0a8a30a8@linux.local> <20040108225657.GB22438@bougret.hpl.hp.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2305 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: 387 Lines: 11 On Thu, 8 Jan 2004 14:56:57 -0800 Jean Tourrilhes wrote: > On Fri, Jan 09, 2004 at 02:03:17PM -0800, Stephen Hemminger wrote: > > Convert IRDA to unsigned length for send/recv msg. > > Ok, I've added that on my web page and will remind Dave if he > doesn't pick it up. Don't worry, I'll queue all of these up for 2.6.2, it's too late for 2.6.1 at this point. From jt@bougret.hpl.hp.com Thu Jan 8 15:47:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 15:48:09 -0800 (PST) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08NluTa007119 for ; Thu, 8 Jan 2004 15:47:56 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id 248531C007DE; Thu, 8 Jan 2004 15:47:56 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_28810+JAGae91741+JAGae92668)/8.9.3 HPLabs Timeshare Server) with ESMTP id PAA09318; Thu, 8 Jan 2004 15:47:55 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1AejsZ-00064I-00; Thu, 08 Jan 2004 15:47:55 -0800 Date: Thu, 8 Jan 2004 15:47:55 -0800 To: "David S. Miller" Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] (12/17) irda -- size_t for send/recvmsg Message-ID: <20040108234755.GA23320@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040109140317.0a8a30a8@linux.local> <20040108225657.GB22438@bougret.hpl.hp.com> <20040108153617.58a75a75.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040108153617.58a75a75.davem@redhat.com> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 2306 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 Content-Length: 573 Lines: 18 On Thu, Jan 08, 2004 at 03:36:17PM -0800, David S. Miller wrote: > On Thu, 8 Jan 2004 14:56:57 -0800 > Jean Tourrilhes wrote: > > > On Fri, Jan 09, 2004 at 02:03:17PM -0800, Stephen Hemminger wrote: > > > Convert IRDA to unsigned length for send/recv msg. > > > > Ok, I've added that on my web page and will remind Dave if he > > doesn't pick it up. > > Don't worry, I'll queue all of these up for 2.6.2, it's too late for 2.6.1 at this > point. Perfect. 2.6.2 is what I was aiming for, it's not like we are in a hurry. Thanks a lot ! Jean From shemminger@osdl.org Thu Jan 8 16:52:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 16:53:04 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i090qoTa011580 for ; Thu, 8 Jan 2004 16:52:50 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i090qgo07604; Thu, 8 Jan 2004 16:52:42 -0800 Date: Thu, 8 Jan 2004 16:53:43 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] bugfixes for dgrs.c Message-Id: <20040108165343.7ed94da9@linux.local> X-Mailer: Sylpheed version 0.9.8claws (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: 2307 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 Content-Length: 12334 Lines: 517 Update the RightSwitch dgrs.c driver for net-drivers-2.5-exp (2.6.1-rc3) to resolve some of the outstanding cruft there. Al may have a better/newer patch. * Don't copy net_device structure on slave device! This won't work because of state variables in structure. * make sure and request_regions before doing i/o to the card * use cpu_relax rather than barrier while spin waiting * don't use dev->init to do the probing work because hard to get unwind correct * Use new pci/eisa probing model, don't search the bus directly Beneficial side effect, don't need to keep on device list anymore. * Be more careful about releaseing resources in error paths Compiled and module loaded/unloaded, but don't have this hardware. diff -Nru a/drivers/net/dgrs.c b/drivers/net/dgrs.c --- a/drivers/net/dgrs.c Thu Jan 8 16:44:05 2004 +++ b/drivers/net/dgrs.c Thu Jan 8 16:44:05 2004 @@ -121,11 +121,22 @@ #include "dgrs_asstruct.h" #include "dgrs_bcomm.h" +#ifdef CONFIG_PCI static struct pci_device_id dgrs_pci_tbl[] = { { SE6_PCI_VENDOR_ID, SE6_PCI_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID, }, { } /* Terminating entry */ }; MODULE_DEVICE_TABLE(pci, dgrs_pci_tbl); +#endif + +#ifdef CONFIG_EISA +static struct eisa_device_id dgrs_eisa_tbl[] = { + { "DBI0A01" }, + { } +}; +MODULE_DEVICE_TABLE(eisa, dgrs_eisa_tbl); +#endif + MODULE_LICENSE("GPL"); @@ -179,11 +190,6 @@ static int dgrs_nicmode; /* - * Chain of device structures - */ -static struct net_device *dgrs_root_dev; - -/* * Private per-board data structure (dev->priv) */ typedef struct @@ -191,7 +197,6 @@ /* * Stuff for generic ethercard I/F */ - struct net_device *next_dev; struct net_device_stats stats; /* @@ -1187,7 +1192,7 @@ priv->intrcnt = 0; for (i = jiffies + 2*HZ + HZ/2; time_after(i, jiffies); ) { - barrier(); /* gcc 2.95 needs this */ + cpu_relax(); if (priv->intrcnt >= 2) break; } @@ -1200,16 +1205,6 @@ } /* - * Register the /proc/ioports information... - */ - if (!request_region(dev->base_addr, 256, "RightSwitch")) { - printk(KERN_ERR "%s: io 0x%3lX, which is busy.\n", dev->name, - dev->base_addr); - rc = -EBUSY; - goto err_free_irq; - } - - /* * Entry points... */ dev->open = &dgrs_open; @@ -1242,22 +1237,23 @@ return (0); } -static int __init +static struct net_device * __init dgrs_found_device( int io, ulong mem, int irq, ulong plxreg, - ulong plxdma + ulong plxdma, + struct device *pdev ) { - DGRS_PRIV *priv; - struct net_device *dev, *aux; - int i, ret; + DGRS_PRIV *priv; + struct net_device *dev; + int i, ret = -ENOMEM; dev = alloc_etherdev(sizeof(DGRS_PRIV)); if (!dev) - return -ENOMEM; + goto err0; priv = (DGRS_PRIV *)dev->priv; @@ -1272,19 +1268,19 @@ priv->chan = 1; priv->devtbl[0] = dev; - dev->init = dgrs_probe1; SET_MODULE_OWNER(dev); - - if (register_netdev(dev) != 0) { - free_netdev(dev); - return -EIO; - } - - priv->next_dev = dgrs_root_dev; - dgrs_root_dev = dev; + SET_NETDEV_DEV(dev, pdev); + + ret = dgrs_probe1(dev); + if (ret) + goto err1; + + ret = register_netdev(dev); + if (ret) + goto err2; if ( !dgrs_nicmode ) - return (0); /* Switch mode, we are done */ + return dev; /* Switch mode, we are done */ /* * Operating card as N separate NICs @@ -1302,8 +1298,7 @@ if (!devN) goto fail; - /* Make it an exact copy of dev[0]... */ - *devN = *dev; + /* Don't copy the network device structure! */ /* copy the priv structure of dev[0] */ privN = (DGRS_PRIV *)devN->priv; @@ -1316,123 +1311,212 @@ devN->irq = 0; /* ... and base MAC address off address of 1st port */ devN->dev_addr[5] += i; - /* ... choose a new name */ - strncpy(devN->name, "eth%d", IFNAMSIZ); - devN->init = dgrs_initclone; + + ret = dgrs_initclone(devN); + if (ret) + goto fail; + SET_MODULE_OWNER(devN); + SET_NETDEV_DEV(dev, pdev); - ret = -EIO; - if (register_netdev(devN)) { + ret = register_netdev(devN); + if (ret) { free_netdev(devN); goto fail; } privN->chan = i+1; priv->devtbl[i] = devN; - privN->next_dev = dgrs_root_dev; - dgrs_root_dev = devN; } - return 0; -fail: aux = priv->next_dev; - while (dgrs_root_dev != aux) { - struct net_device *d = dgrs_root_dev; - - dgrs_root_dev = ((DGRS_PRIV *)d->priv)->next_dev; + return dev; + + fail: + while (i >= 0) { + struct net_device *d = priv->devtbl[i--]; unregister_netdev(d); free_netdev(d); } - return ret; + + err2: + free_irq(dev->irq, dev); + err1: + free_netdev(dev); + err0: + return ERR_PTR(ret); } -/* - * Scan for all boards - */ -static int is2iv[8] __initdata = { 0, 3, 5, 7, 10, 11, 12, 15 }; +static void __devexit dgrs_remove(struct net_device *dev) +{ + DGRS_PRIV *priv = dev->priv; + int i; + + unregister_netdev(dev); + + for (i = 1; i < priv->nports; ++i) { + struct net_device *d = priv->devtbl[i]; + if (d) { + unregister_netdev(d); + free_netdev(d); + } + } + + proc_reset(priv->devtbl[0], 1); -static int __init dgrs_scan(void) + if (priv->vmem) + iounmap(priv->vmem); + if (priv->vplxdma) + iounmap((uchar *) priv->vplxdma); + + if (dev->irq) + free_irq(dev->irq, dev); + + for (i = 1; i < priv->nports; ++i) { + if (priv->devtbl[i]) + unregister_netdev(priv->devtbl[i]); + } +} + +#ifdef CONFIG_PCI +static int __init dgrs_pci_probe(struct pci_dev *pdev, + const struct pci_device_id *ent) { - int cards_found = 0; + struct net_device *dev; + int err; uint io; uint mem; uint irq; uint plxreg; uint plxdma; - struct pci_dev *pdev = NULL; /* - * First, check for PCI boards - */ - while ((pdev = pci_find_device(SE6_PCI_VENDOR_ID, SE6_PCI_DEVICE_ID, pdev)) != NULL) - { - /* - * Get and check the bus-master and latency values. - * Some PCI BIOSes fail to set the master-enable bit, - * and the latency timer must be set to the maximum - * value to avoid data corruption that occurs when the - * timer expires during a transfer. Yes, it's a bug. - */ - if (pci_enable_device(pdev)) - continue; - pci_set_master(pdev); - - plxreg = pci_resource_start (pdev, 0); - io = pci_resource_start (pdev, 1); - mem = pci_resource_start (pdev, 2); - pci_read_config_dword(pdev, 0x30, &plxdma); - irq = pdev->irq; - plxdma &= ~15; + * Get and check the bus-master and latency values. + * Some PCI BIOSes fail to set the master-enable bit, + * and the latency timer must be set to the maximum + * value to avoid data corruption that occurs when the + * timer expires during a transfer. Yes, it's a bug. + */ + err = pci_enable_device(pdev); + if (err) + return err; + err = pci_request_regions(pdev, "RightSwitch"); + if (err) + return err; + + pci_set_master(pdev); + + plxreg = pci_resource_start (pdev, 0); + io = pci_resource_start (pdev, 1); + mem = pci_resource_start (pdev, 2); + pci_read_config_dword(pdev, 0x30, &plxdma); + irq = pdev->irq; + plxdma &= ~15; + + /* + * On some BIOSES, the PLX "expansion rom" (used for DMA) + * address comes up as "0". This is probably because + * the BIOS doesn't see a valid 55 AA ROM signature at + * the "ROM" start and zeroes the address. To get + * around this problem the SE-6 is configured to ask + * for 4 MB of space for the dual port memory. We then + * must set its range back to 2 MB, and use the upper + * half for DMA register access + */ + OUTL(io + PLX_SPACE0_RANGE, 0xFFE00000L); + if (plxdma == 0) + plxdma = mem + (2048L * 1024L); + pci_write_config_dword(pdev, 0x30, plxdma + 1); + pci_read_config_dword(pdev, 0x30, &plxdma); + plxdma &= ~15; + + dev = dgrs_found_device(io, mem, irq, plxreg, plxdma, &pdev->dev); + if (IS_ERR(dev)) { + pci_release_regions(pdev); + return PTR_ERR(dev); + } - /* - * On some BIOSES, the PLX "expansion rom" (used for DMA) - * address comes up as "0". This is probably because - * the BIOS doesn't see a valid 55 AA ROM signature at - * the "ROM" start and zeroes the address. To get - * around this problem the SE-6 is configured to ask - * for 4 MB of space for the dual port memory. We then - * must set its range back to 2 MB, and use the upper - * half for DMA register access - */ - OUTL(io + PLX_SPACE0_RANGE, 0xFFE00000L); - if (plxdma == 0) - plxdma = mem + (2048L * 1024L); - pci_write_config_dword(pdev, 0x30, plxdma + 1); - pci_read_config_dword(pdev, 0x30, &plxdma); - plxdma &= ~15; + pci_set_drvdata(pdev, dev); + return 0; +} - dgrs_found_device(io, mem, irq, plxreg, plxdma); +static void __devexit dgrs_pci_remove(struct pci_dev *pdev) +{ + struct net_device *dev = pci_get_drvdata(pdev); - cards_found++; - } + dgrs_remove(dev); + pci_release_regions(pdev); + free_netdev(dev); +} - /* - * Second, check for EISA boards - */ - if (EISA_bus) - { - for (io = 0x1000; io < 0x9000; io += 0x1000) - { - if (inb(io+ES4H_MANUFmsb) != 0x10 - || inb(io+ES4H_MANUFlsb) != 0x49 - || inb(io+ES4H_PRODUCT) != ES4H_PRODUCT_CODE) - continue; +static struct pci_driver dgrs_pci_driver = { + .name = "dgrs", + .id_table = dgrs_pci_tbl, + .probe = dgrs_pci_probe, + .remove = __devexit_p(dgrs_pci_remove), +}; +#endif + + +#ifdef CONFIG_EISA +static int is2iv[8] __initdata = { 0, 3, 5, 7, 10, 11, 12, 15 }; - if ( ! (inb(io+ES4H_EC) & ES4H_EC_ENABLE) ) - continue; /* Not EISA configured */ +static int __init dgrs_eisa_probe (struct device *gendev) +{ + struct net_device *dev; + struct eisa_device *edev = to_eisa_device(gendev); + uint io = edev->base_addr; + uint mem; + uint irq; + int rc = -ENODEV; /* Not EISA configured */ + + if (!request_region(io, 256, "RightSwitch")) { + printk(KERN_ERR "%s: io 0x%3lX, which is busy.\n", dev->name, + dev->base_addr); + return -EBUSY; + } - mem = (inb(io+ES4H_AS_31_24) << 24) - + (inb(io+ES4H_AS_23_16) << 16); + if ( ! (inb(io+ES4H_EC) & ES4H_EC_ENABLE) ) + goto err_out; - irq = is2iv[ inb(io+ES4H_IS) & ES4H_IS_INTMASK ]; + mem = (inb(io+ES4H_AS_31_24) << 24) + + (inb(io+ES4H_AS_23_16) << 16); - dgrs_found_device(io, mem, irq, 0L, 0L); + irq = is2iv[ inb(io+ES4H_IS) & ES4H_IS_INTMASK ]; - ++cards_found; - } + dev = dgrs_found_device(io, mem, irq, 0L, 0L, gendev); + if (IS_ERR(dev)) { + rc = PTR_ERR(dev); + goto err_out; } - return cards_found; + gendev->driver_data = dev; + return 0; + err_out: + release_region(io, 256); + return rc; +} + +static int __devexit dgrs_eisa_remove(struct device *gendev) +{ + struct net_device *dev = gendev->driver_data; + + dgrs_remove(dev); + + release_region(dev->base_addr, 256); + + free_netdev(dev); + return 0; } +static struct eisa_driver dgrs_eisa_driver = { + .id_table = dgrs_eisa_tbl, + .driver = { + .name = "dgrs", + .probe = dgrs_eisa_probe, + .remove = __devexit_p(dgrs_eisa_remove), + } +}; +#endif + /* * Variables that can be overriden from module command line */ @@ -1459,8 +1543,8 @@ static int __init dgrs_init_module (void) { - int cards_found; int i; + int eisacount = 0, pcicount = 0; /* * Command line variable overrides @@ -1501,38 +1585,27 @@ /* * Find and configure all the cards */ - dgrs_root_dev = NULL; - cards_found = dgrs_scan(); - - return cards_found ? 0 : -ENODEV; +#ifdef CONFIG_EISA + eisacount = eisa_driver_register(&dgrs_eisa_driver); + if (eisacount < 0) + return eisacount; +#endif +#ifdef CONFIG_PCI + pcicount = pci_register_driver(&dgrs_pci_driver); + if (pcicount < 0) + return pcicount; +#endif + return (eisacount + pcicount) == 0 ? -ENODEV : 0; } static void __exit dgrs_cleanup_module (void) { - while (dgrs_root_dev) - { - struct net_device *next_dev; - DGRS_PRIV *priv; - - priv = (DGRS_PRIV *) dgrs_root_dev->priv; - next_dev = priv->next_dev; - unregister_netdev(dgrs_root_dev); - - proc_reset(priv->devtbl[0], 1); - - if (priv->vmem) - iounmap(priv->vmem); - if (priv->vplxdma) - iounmap((uchar *) priv->vplxdma); - - release_region(dgrs_root_dev->base_addr, 256); - - if (dgrs_root_dev->irq) - free_irq(dgrs_root_dev->irq, dgrs_root_dev); - - free_netdev(dgrs_root_dev); - dgrs_root_dev = next_dev; - } +#ifdef CONFIG_EISA + eisa_driver_unregister (&dgrs_eisa_driver); +#endif +#ifdef CONFIG_PCI + pci_unregister_driver (&dgrs_pci_driver); +#endif } module_init(dgrs_init_module); From willy@w.ods.org Thu Jan 8 16:54:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 16:54:47 -0800 (PST) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i090sWTa011747 for ; Thu, 8 Jan 2004 16:54:33 -0800 Date: Fri, 9 Jan 2004 01:54:23 +0100 From: Willy Tarreau To: Nathaniel M Nelson Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Possible weird TCP/IP bug Message-ID: <20040109005423.GD545@alpha.home.local> References: <3FFDDE33.1070006@chartermi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FFDDE33.1070006@chartermi.net> User-Agent: Mutt/1.4i X-archive-position: 2308 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 Content-Length: 917 Lines: 18 You should post this with more information to netdev@oss.sgi.com. Please describe your setup a bit. Where do the packets originate. Are they forwarded by the firewall or emitted by it ? In the later case, are they generated by a local process or are they replies ? etc... Willy On Thu, Jan 08, 2004 at 05:48:19PM -0500, Nathaniel M Nelson wrote: > I have 3 machines running 2.4.22 (Slackware 9.1) and only one of them, > which happens to be my firewall, sends out TCP sequence numbers starting > with "0". This does not seem right to me. If this is not a bug, I > apoligize...if anyone thinks it might be, please tell me if you need > more in-depth info. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From nmn@chartermi.net Thu Jan 8 20:22:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 20:22:30 -0800 (PST) Received: from proxy3-baycity.chartermi.net (proxy3baymi.bay.mi.charter.com [24.247.24.41]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i094MGTa019639 for ; Thu, 8 Jan 2004 20:22:16 -0800 Received: from chartermi.net (24.231.146.33.gha.mi.chartermi.net [24.231.146.33] (may be forged)) by proxy3-baycity.chartermi.net (8.11.7p1+Sun/8.11.6) with ESMTP id i094M5A09755 for ; Thu, 8 Jan 2004 23:22:05 -0500 (EST) Message-ID: <3FFE2B00.2030607@chartermi.net> Date: Thu, 08 Jan 2004 23:16:00 -0500 From: Nathaniel M Nelson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Possible weird TCP bug Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Charter-MailScanner-Information: X-Charter-MailScanner: X-archive-position: 2309 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nmn@chartermi.net Precedence: bulk X-list: netdev Content-Length: 1880 Lines: 34 I have encountered a strange issue with one of my linux machines (which happens to be my firewall/masquerading box)....it seems that the TCP sequence numbers that it generates for output start with "0". This goes for any packet that originates from the firewall itself or any packets that are forwarded to that machine. This does not seem right to me...any other linux box that I hook up to the WAN looks like they generate a normal sequence number. This particular system is running a Tyan Thunder/LE-T 2518GN motherboard which is a Dual Socket 370 board. It has two Intel 82559 LAN controllers. Let me know if anyone needs more specs. It was running the 2.4.22 kernel and now runs the 2.4.24 kernel and both have the same tcp sequence problem. Below is a sample SYN packet going out to google.com. It has a sequence # of "0". 0000 00 02 7d 66 a4 54 00 e0 81 23 14 78 08 00 45 00 ..}f.T.. .#.x..E. 0010 00 3c 9a 41 40 00 3f 06 f4 1f 18 e7 92 21 d8 ef .<.A@.?. .....!.. 0020 29 63 89 37 00 50 e5 4b 22 e0 00 00 00 00 a0 02 )c.7.P.K "....... 0030 16 d0 36 6a 00 00 02 04 05 b4 04 02 08 0a 03 1d ..6j.... ........ 0040 b8 a1 00 00 00 00 01 03 03 00 ........ .. Then after I get the SYN,ACK back, the firewall will send out the next ACK with the sequence number correctly incremented by 1. 0000 00 02 7d 66 a4 54 00 e0 81 23 14 78 08 00 45 00 ..}f.T.. .#.x..E. 0010 00 28 9a 42 40 00 3f 06 f4 32 18 e7 92 21 d8 ef .(.B@.?. .2...!.. 0020 29 63 89 37 00 50 e5 4b 22 e1 db f2 5c c5 50 10 )c.7.P.K "...\.P. 0030 16 d0 21 3d 00 00 ..!=. So of course the sequence is "1" in that packet. Both sequence numbers seem a little low though... and not very cryptic. If this is not a bug I apoligize in advance. (Please CC replies to nmn@chartermi.net as I am not subscribed.) From michal@logix.cz Fri Jan 9 00:51:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 00:51:26 -0800 (PST) Received: from maxipes.logix.cz (maxipes.logix.cz [81.0.234.97]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i098pATa028999 for ; Fri, 9 Jan 2004 00:51:13 -0800 Received: from logix.cz (styx.suse.cz [213.210.157.162]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "Michal Ludvig", Issuer "Personal Freemail RSA 2000.8.30" (verified OK)) by maxipes.logix.cz (Postfix) with ESMTP id 71147299F3; Fri, 9 Jan 2004 09:51:08 +0100 (CET) Message-ID: <3FFE6B72.9030808@logix.cz> Date: Fri, 09 Jan 2004 09:50:58 +0100 From: Michal Ludvig User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: cs, cz, en MIME-Version: 1.0 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] sha2-256 truncation Content-Type: multipart/mixed; boundary="------------090003070806070002080905" X-archive-position: 2310 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michal@logix.cz Precedence: bulk X-list: netdev Content-Length: 1233 Lines: 40 This is a multi-part message in MIME format. --------------090003070806070002080905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, the attached trivial patch corrects the truncation size of computed hashes that are used in IPsec ESP/AH packets for SHA2-256. All other hash algorithms use 96 bits as well as does SuperFreeS/WAN and FreeBSD also for SHA2-256. Only the native Linux sha2-256 used 128 bits what led to incompatibility with other IPsec implementations. Please apply, thanks! Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal --------------090003070806070002080905 Content-Type: text/plain; name="kernel-sha256.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kernel-sha256.diff" --- linux-2.6.0/net/xfrm/xfrm_algo.c 2004-01-08 01:29:52.067261651 +0100 +++ linux-2.6.0.orig/net/xfrm/xfrm_algo.c 2004-01-08 01:28:38.668690081 +0100 @@ -85,7 +85,7 @@ static struct xfrm_algo_desc aalg_list[] .uinfo = { .auth = { - .icv_truncbits = 96, + .icv_truncbits = 128, .icv_fullbits = 256, } }, --------------090003070806070002080905-- From andi@muc.de Fri Jan 9 01:09:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 01:09:37 -0800 (PST) Received: from averell.firstfloor.org (niemand@pD95263A3.dip.t-dialin.net [217.82.99.163]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0999ETa029721 for ; Fri, 9 Jan 2004 01:09:15 -0800 Received: from averell.firstfloor.org (localhost [127.0.0.1]) by averell.firstfloor.org (8.12.6/8.12.6/SuSE Linux 0.6) with ESMTP id i0999BpL001815; Fri, 9 Jan 2004 10:09:11 +0100 Received: (from andi@localhost) by averell.firstfloor.org (8.12.6/8.12.6/Submit) id i09998YV001814; Fri, 9 Jan 2004 10:09:08 +0100 Date: Fri, 9 Jan 2004 10:09:08 +0100 From: Andi Kleen To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, mikep@linuxtr.net, linux-tr@linuxtr.net Subject: [PATCH] Mark IBM TR driver as not 64 bit clean Message-ID: <20040109090908.GA1772@averell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 2311 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: 764 Lines: 18 This driver doesn't seem to be 64bit clean judging from the warnings on x86-64. Mark it as !64BIT. -Andi diff -burpN -X ../KDIFX linux-vanilla/drivers/net/pcmcia/Kconfig linux-2.6.1-amd64/drivers/net/pcmcia/Kconfig --- linux-vanilla/drivers/net/pcmcia/Kconfig 2003-09-28 10:55:00.000000000 +0200 +++ linux-2.6.1-amd64/drivers/net/pcmcia/Kconfig 2004-01-01 06:56:50.000000000 +0100 @@ -119,7 +119,7 @@ config ARCNET_COM20020_CS config PCMCIA_IBMTR tristate "IBM PCMCIA tokenring adapter support" - depends on NET_PCMCIA && IBMTR!=y && TR && PCMCIA + depends on NET_PCMCIA && IBMTR!=y && TR && PCMCIA && !64BIT help Say Y here if you intend to attach this type of Token Ring PCMCIA card to your computer. You then also need to say Y to "Token Ring From davem@pizda.ninka.net Fri Jan 9 02:01:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 02:01:51 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i09A1bTa031701 for ; Fri, 9 Jan 2004 02:01:38 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id BAA04474; Fri, 9 Jan 2004 01:55:27 -0800 Date: Fri, 9 Jan 2004 01:55:27 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] (1/17) protocol sendmsg/revmsg prototype Message-Id: <20040109015527.1131a9ab.davem@redhat.com> In-Reply-To: <20040109132658.01aa28dd@linux.local> References: <20040109132658.01aa28dd@linux.local> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2312 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: 275 Lines: 9 On Fri, 9 Jan 2004 13:26:58 -0800 Stephen Hemminger wrote: > The first patch changes the prototype, and causes all the protocols to > generate warnings that are cleared up in the next sixteen. All added to my 2.6.2-preX pending tree. Thanks Stephen. From davem@pizda.ninka.net Fri Jan 9 02:07:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 02:07:17 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i09A74Ta032160 for ; Fri, 9 Jan 2004 02:07:04 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id CAA04513; Fri, 9 Jan 2004 02:00:43 -0800 Date: Fri, 9 Jan 2004 02:00:43 -0800 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com, ajz@cambridgebroadband.com Subject: Re: [PATCH][ATM]: br2684 incorrectly handles frames recvd with FCS (by Alex Zeffertt ) Message-Id: <20040109020043.223dc1b1.davem@redhat.com> In-Reply-To: <200401081658.i08GwdRr017374@ginger.cmf.nrl.navy.mil> References: <200401081658.i08GwdRr017374@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2313 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: 164 Lines: 6 On Thu, 08 Jan 2004 11:58:40 -0500 chas williams (contractor) wrote: > please apply to 2.6 (and 2.4 as well!) Applied, thanks a lot Chas. From davem@pizda.ninka.net Fri Jan 9 02:11:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 02:11:21 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i09AB8Ta001049 for ; Fri, 9 Jan 2004 02:11:08 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id CAA04592; Fri, 9 Jan 2004 02:04:56 -0800 Date: Fri, 9 Jan 2004 02:04:56 -0800 From: "David S. Miller" To: Andi Kleen Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Mark SIOCSIFNAME as compatible ioctl Message-Id: <20040109020456.045b447e.davem@redhat.com> In-Reply-To: <20040108070413.GA31778@averell> References: <20040108070413.GA31778@averell> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2314 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: 293 Lines: 10 On Thu, 8 Jan 2004 08:04:13 +0100 Andi Kleen wrote: > Mark SIOCSIFNAME as an ioctl that doesn't need 32bit conversion. > > Fixes nameif as 32bit executable. How can we mark it compatible? It needs the stuff dev_ifname32() in fs/compat_ioctl.c does for SIOCGIFNAME doesn't it? From michal@logix.cz Fri Jan 9 02:51:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 02:51:15 -0800 (PST) Received: from maxipes.logix.cz (maxipes.logix.cz [81.0.234.97]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i09AooTa005787 for ; Fri, 9 Jan 2004 02:50:51 -0800 Received: from logix.cz (styx.suse.cz [213.210.157.162]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "Michal Ludvig", Issuer "Personal Freemail RSA 2000.8.30" (verified OK)) by maxipes.logix.cz (Postfix) with ESMTP id 8ACC029A1C; Fri, 9 Jan 2004 11:12:46 +0100 (CET) Message-ID: <3FFE7E98.6060201@logix.cz> Date: Fri, 09 Jan 2004 11:12:40 +0100 From: Michal Ludvig User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: cs, cz, en MIME-Version: 1.0 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] sha2-256 truncation References: <3FFE6B72.9030808@logix.cz> In-Reply-To: <3FFE6B72.9030808@logix.cz> Content-Type: multipart/mixed; boundary="------------080108030503020203040007" X-archive-position: 2315 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michal@logix.cz Precedence: bulk X-list: netdev Content-Length: 1324 Lines: 42 This is a multi-part message in MIME format. --------------080108030503020203040007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michal Ludvig told me that: > the attached trivial patch corrects the truncation size of computed > hashes that are used in IPsec ESP/AH packets for SHA2-256. All other > hash algorithms use 96 bits as well as does SuperFreeS/WAN and FreeBSD > also for SHA2-256. Only the native Linux sha2-256 used 128 bits what led > to incompatibility with other IPsec implementations. Oops, sorry. I sent a reversed patch originally. Please use this one instead. Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal --------------080108030503020203040007 Content-Type: text/plain; name="kernel-sha256.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kernel-sha256.diff" --- linux-2.6.0/net/xfrm/xfrm_algo.c 2004-01-08 01:29:52.067261651 +0100 +++ linux-2.6.0.orig/net/xfrm/xfrm_algo.c 2004-01-08 01:28:38.668690081 +0100 @@ -85,7 +85,7 @@ static struct xfrm_algo_desc aalg_list[] .uinfo = { .auth = { - .icv_truncbits = 128, + .icv_truncbits = 96, .icv_fullbits = 256, } }, --------------080108030503020203040007-- From Holger.Kiehl@dwd.de Fri Jan 9 07:01:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 07:01:34 -0800 (PST) Received: from dwdmx2.dwd.de (dwdmx2.dwd.de [141.38.3.197]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i09F1ETa017191 for ; Fri, 9 Jan 2004 07:01:15 -0800 Received: (qmail 6968996 invoked from network); 9 Jan 2004 15:01:12 -0000 Received: from mhofsv1.dwd.de (141.38.32.42) by dwdmx2.dwd.de with SMTP; 9 Jan 2004 15:01:12 -0000 Received: from praktifix.dwd.de by mhofsv1.dwd.de with ESMTP for netdev@oss.sgi.com; Fri, 9 Jan 2004 16:01:12 +0100 Date: Fri, 9 Jan 2004 15:01:12 +0000 (GMT) From: Holger Kiehl X-X-Sender: kiehl@praktifix.dwd.de To: netdev@oss.sgi.com Subject: Re: Problems with ipv4 multicast implementation in 2.4? (fwd) In-Reply-To: Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-archive-position: 2317 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Holger.Kiehl@dwd.de Precedence: bulk X-list: netdev Content-Length: 9093 Lines: 166 Hello The problem has been resolved by Rafal Malek from tellique, here his reasoning: Each network device supports sending and receiving of data packets by default. But, in case of one-way satellite communication (used by your TelliCast service) the device is not able to send data - it only receives. So, if the DVB device (configured as a network interface) wants to send data (e.g. broadcasts for its own subnet) the data cannot be delivered and the packets' information is cached, the DVB driver does _not_ free the buffer of the packets which should be sent. Both the drivers from linuxtv.org and the open source driver from the pent@value card have this error. Simply inserting a dev_kfree_skb(skb) in the dvb_net_tx() (linuxtv.org) / PentaVal_start_xmit() (pent@value) function solved this problem. Rafal Malek verified this for the linuxtv.org driver and I did it for the pent@value driver. Here the relevant values for a system with a pent@value card and nearly 23 days uptime: ip_dst_cache 270 270 256 18 18 1 : 252 126 skbuff_head_cache 795 795 256 53 53 1 : 252 126 size-2048 452 482 2048 238 241 1 : 60 30 Thank you to all the people who helped to find this error! Unfortunatly there still is another leak, the dentry_cache value does not go down. But this problem does not belong to this list. Holger On Fri, 14 Nov 2003, Holger Kiehl wrote: > Sorry for cross posting this message, but it has been pointed out that > linux-kernel is the wrong list for this question. > > Hello > > We have about 25 systems that receive data via a pci DVB card from satellite. > The data is received through multiple muticast streams by some closed > source software. On all systems we notice that the free memory decreases > until in most cases the system are no longer reachable via network. They > then constantly print out: dst cache overflow. But I also have noticed that > some systems lock up hard, I assume this is because we just increase > the ip_dst_cache in /proc/sys/net/ipv4/route/max_size to some very > large value. > > I also know that the German Telekom and Eumetsat have the same problems > and always have to reboot their systems. I also have reports from Austria > and expect many more systems in Europe are effected. > > To get more information I have setup 3 systems with different kernels and > hardware and noticed that over the time ip_dst_cache and skbuff_head_cache > in /proc/slabinfo always increase. They never go down. Also one or more of > the of the size-x values always increase depending on the kernel and DVB > card being used. Here some more slabinfo details and hardware being used: > > System1 : PIII 450MHz, 256MB ram, Kernel 2.4.23-pre9, pent@value DVB card > System2 : PII 350MHz, 384MB ram, Kernel 2.4.21, pent@value DVB card > System3 : P4 2.4GHz with HT enabled, 1 GB ram (high mem enabled), > Kernel 2.4.23-rc1 and libata patch, Nova-S DVB card > > Now the slabinfo data every 24 hours: > > System1: > > ip_dst_cache 647 672 160 27 28 1 > ip_dst_cache 7444 7464 160 311 311 1 > ip_dst_cache 14339 14352 160 598 598 1 > ip_dst_cache 21106 21120 160 880 880 1 > ip_dst_cache 28101 28104 160 1171 1171 1 > > skbuff_head_cache 796 1008 160 41 42 1 > skbuff_head_cache 7588 7824 160 326 326 1 > skbuff_head_cache 14482 14688 160 612 612 1 > skbuff_head_cache 21258 21480 160 895 895 1 > skbuff_head_cache 28255 28416 160 1184 1184 1 > > size-2048 685 968 2048 343 484 1 > size-2048 7483 7676 2048 3742 3838 1 > size-2048 14376 14398 2048 7188 7199 1 > size-2048 21146 21216 2048 10573 10608 1 > size-2048 28142 28292 2048 14071 14146 1 > > System2: > > ip_dst_cache 9 48 160 1 2 1 > ip_dst_cache 7437 7464 160 311 311 1 > ip_dst_cache 15161 15168 160 632 632 1 > ip_dst_cache 18831 18840 160 785 785 1 > > skbuff_head_cache 14 24 160 1 1 1 > skbuff_head_cache 11482 12168 160 500 507 1 > skbuff_head_cache 23312 23904 160 996 996 1 > skbuff_head_cache 28900 29640 160 1235 1235 1 > > size-128 611 660 128 21 22 1 > size-128 11987 12210 128 402 407 1 > size-128 23800 23970 128 798 799 1 > size-128 29445 29670 128 983 989 1 > > > Slabinfo for every 12 hours and CONFIG_DEBUG_SLAB set: > > System3: > > ip_dst_cache 576 576 160 24 24 1 : 576 576 24 0 0 : 252 126 : 1946 48 1426 0 > ip_dst_cache 17760 17760 160 740 740 1 : 17760 17760 740 0 0 : 252 126 : 46553 1480 29557 0 > ip_dst_cache 35376 35376 160 1474 1474 1 : 35376 36403 1474 0 0 : 252 126 : 94140 3014 60309 0 > ip_dst_cache 51624 51624 160 2151 2151 1 : 51624 53444 2151 0 0 : 252 126 : 138864 4431 89547 0 > > skbuff_head_cache 1311 1311 168 57 57 1 : 1311 79557 57 0 0 : 252 126 : 82108 735 81114 621 > skbuff_head_cache 18492 18492 168 804 804 1 : 18492 3300792 804 0 0 : 252 126 : 3320868 27658 3303434 26050 > skbuff_head_cache 36133 36133 168 1571 1571 1 : 36133 6652585 1583 12 0 : 252 126 : 6684139 55715 6649977 52420 > skbuff_head_cache 52371 52371 168 2277 2277 1 : 52371 9913620 2294 17 0 : 252 126 : 9957116 82923 9907545 78097 > > size-8192 540 540 8192 540 540 2 : 540 3196 540 0 0 : 0 0 : 0 0 0 0 > size-8192 17736 17738 8192 17736 17738 2 : 17738 23194 17738 0 0 : 0 0 : 0 0 0 0 > size-8192 35367 35367 8192 35367 35367 2 : 35367 43715 35374 7 0 : 0 0 : 0 0 0 0 > size-8192 51596 51598 8192 51596 51598 2 : 51598 62824 51611 13 0 : 0 0 : 0 0 0 0 > > size-2048 452 512 2048 240 256 1 : 512 75002 256 0 0 : 60 30 : 140293 2995 140145 2485 > size-2048 454 514 2048 238 257 1 : 514 3029044 257 0 0 : 60 30 : 5130850 101465 5130703 100953 > size-2048 456 486 2048 241 243 1 : 530 6113873 593 350 0 : 60 30 : 10457205 204975 10457530 203655 > size-2048 454 484 2048 239 242 1 : 542 9104228 1042 800 0 : 60 30 : 15398297 305608 15399447 303014 > > size-128 2016 2268 136 78 81 1 : 2268 9125 81 0 0 : 252 126 : 23644 195 22128 56 > size-128 19096 19096 136 682 682 1 : 19096 26457 682 0 0 : 252 126 : 131136 1401 113018 58 > size-128 36708 36708 136 1311 1311 1 : 36708 59707 1317 6 0 : 252 126 : 255889 2833 220918 144 > size-128 52920 52920 136 1890 1890 1 : 52920 81855 1911 21 0 : 252 126 : 370264 4135 319786 153 > > size-64 7844 7844 72 148 148 1 : 7844 7931 148 0 0 : 252 126 : 15660 253 9102 0 > size-64 18497 18497 72 349 349 1 : 18497 18584 349 0 0 : 252 126 : 110763 655 93784 0 > size-64 24963 24963 72 471 471 1 : 24963 32458 471 0 0 : 252 126 : 209402 1008 186275 0 > size-64 34503 34503 72 651 651 1 : 34503 48900 651 0 0 : 252 126 : 305026 1613 272674 0 > > There is much more data available, the full slabinfo was taken every > hour for each system. Additionally with the help of Jörn Engel I managed > to setup System1 with gcov kernel patch and have all data available on > an hourly basis until the system has reached "dst cache overflow". I have > tried very hard to evaluate this data myself, but find that the linux > network code is way beyond my c programming knowledge. > > Another thing noticed is that as the memory usage increases the systems > become slower, when you log in on them and work there. > > Has anyone any suggestion of what else I can do to narrow down the problem? > > What I am also not sure if it is correct to assume the bug in the ipv4 > multicast implementation, or can it still be a driver problem? But I assume > two completely different drivers make this very unlikely. > > Please, can someone help me to find the bug. I am willing to do any tests > or provide more information. > > Thanks, > Holger > > PS: Please cc me, since I am not on the list. > > > -- From ak@suse.de Fri Jan 9 08:28:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 08:28:59 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i09GSZTa027847 for ; Fri, 9 Jan 2004 08:28:35 -0800 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 B12C519B779C; Fri, 9 Jan 2004 16:56:28 +0100 (CET) Date: Fri, 9 Jan 2004 16:56:27 +0100 From: Andi Kleen To: "David S. Miller" Cc: ak@muc.de, netdev@oss.sgi.com Subject: Re: [PATCH] Mark SIOCSIFNAME as compatible ioctl Message-Id: <20040109165627.2e0845af.ak@suse.de> In-Reply-To: <20040109020456.045b447e.davem@redhat.com> References: <20040108070413.GA31778@averell> <20040109020456.045b447e.davem@redhat.com> X-Mailer: Sylpheed version 0.9.7 (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: 2318 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 Content-Length: 793 Lines: 33 On Fri, 9 Jan 2004 02:04:56 -0800 "David S. Miller" wrote: > On Thu, 8 Jan 2004 08:04:13 +0100 > Andi Kleen wrote: > > > Mark SIOCSIFNAME as an ioctl that doesn't need 32bit conversion. > > > > Fixes nameif as 32bit executable. > > How can we mark it compatible? It needs the stuff dev_ifname32() in > fs/compat_ioctl.c does for SIOCGIFNAME doesn't it? It takes two strings. This should be compatible: struct ifreq { union { char ifrn_name[IFNAMSIZ]; /* if name, e.g. "en0" */ / } ifr_ifrn; union { ... char ifru_newname[IFNAMSIZ]; ... } ifr_ifru; }; -Andi P.S.: Maybe it would be time update the "en0" comment in if.h too ;-) I bet that comes from VAX/BSD. From krkumar@us.ibm.com Fri Jan 9 17:48:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 17:48:16 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0A1luTa015969 for ; Fri, 9 Jan 2004 17:48:03 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0A1lod6386116; Fri, 9 Jan 2004 20:47:50 -0500 Received: from linux-udp15191261uds.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0A1lmqb107198; Fri, 9 Jan 2004 20:47:49 -0500 Date: Fri, 9 Jan 2004 17:40:03 -0800 (PST) From: Krishna Kumar X-X-Sender: krkumar@linux-udp14999547uds To: "David S. Miller" cc: netdev@oss.sgi.com, KK , Subject: [PATCH] Bugs in xfrm In-Reply-To: <20031108223049.36651f8d.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2319 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 5781 Lines: 171 Hi Dave, The following look to be bugs in xfrm related code. 1. In xfrm_lookup, a couple of bugs : - the found or allocated xfrm_states are not passed correctly to xfrm_bundle_create (and to the subsequent frees in case of create failing) if the first xfrm_tmpl_resolve failed and the second one succeeded. - error handling is wrong. 2. In pfkey_get(), the xfrm_state is dereferenced after it is dropped, which could lead to dereferencing freed memory. 3. ipcomp_tunnel_create and xfrm_state_construct don't set x->km.state to XFRM_STATE_DEAD. This can lead to the BUG_TRAP in __xfrm_state_destroy when xfrm_state_put() finds this is the last reference. This was reported as one of the problems of [Bug 1754] some time back. 4. I am not sure of this one. I think dst_free() cannot be used when a bundle of dst's are allocated and have to be freed. We need a new dst_bundle_free() routine to free all linked dst's ?? Change is in __xfrm[46]_bundle_create & xfrm_lookup(), the lookup one I am not very sure. Why are we doing a dst_put(), shouldn't this be a free of all dst's off the dst->child list since the routine marking 'dead' cleared all entries off the dst->next list ? These changes compile cleanly, but I couldn't test since these are corner cases. Please let me know if this can be applied. I am sending as one patch file for now instead of multiple files as they all small. Thanks, - KK diff -ruN linux-2.6.0-rc2-bk6.org/include/net/dst.h linux-2.6.0-rc2-bk6/include/net/dst.h --- linux-2.6.0-rc2-bk6.org/include/net/dst.h 2004-01-09 17:08:18.000000000 -0800 +++ linux-2.6.0-rc2-bk6/include/net/dst.h 2004-01-09 17:08:55.000000000 -0800 @@ -168,6 +168,7 @@ extern void * dst_alloc(struct dst_ops * ops); extern void __dst_free(struct dst_entry * dst); +extern void dst_bundle_free(struct dst_entry * dst); extern struct dst_entry *dst_destroy(struct dst_entry * dst); static inline void dst_free(struct dst_entry * dst) diff -ruN linux-2.6.0-rc2-bk6.org/net/ipv4/ipcomp.c linux-2.6.0-rc2-bk6/net/ipv4/ipcomp.c --- linux-2.6.0-rc2-bk6.org/net/ipv4/ipcomp.c 2004-01-05 13:43:50.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/ipv4/ipcomp.c 2004-01-09 13:00:22.000000000 -0800 @@ -294,6 +294,7 @@ return t; error: + t->km.state = XFRM_STATE_DEAD; xfrm_state_put(t); t = NULL; goto out; diff -ruN linux-2.6.0-rc2-bk6.org/net/ipv4/xfrm4_policy.c linux-2.6.0-rc2-bk6/net/ipv4/xfrm4_policy.c --- linux-2.6.0-rc2-bk6.org/net/ipv4/xfrm4_policy.c 2004-01-09 15:02:48.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/ipv4/xfrm4_policy.c 2004-01-09 16:11:57.000000000 -0800 @@ -162,7 +162,7 @@ error: if (dst) - dst_free(dst); + dst_bundle_free(dst); return err; } diff -ruN linux-2.6.0-rc2-bk6.org/net/ipv6/xfrm6_policy.c linux-2.6.0-rc2-bk6/net/ipv6/xfrm6_policy.c --- linux-2.6.0-rc2-bk6.org/net/ipv6/xfrm6_policy.c 2004-01-09 16:43:45.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/ipv6/xfrm6_policy.c 2004-01-09 16:44:03.000000000 -0800 @@ -184,7 +184,7 @@ error: if (dst) - dst_free(dst); + dst_bundle_free(dst); return err; } diff -ruN linux-2.6.0-rc2-bk6.org/net/key/af_key.c linux-2.6.0-rc2-bk6/net/key/af_key.c --- linux-2.6.0-rc2-bk6.org/net/key/af_key.c 2004-01-05 13:45:47.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/key/af_key.c 2004-01-09 12:41:30.000000000 -0800 @@ -1283,6 +1283,7 @@ static int pfkey_get(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { + __u8 proto; struct sk_buff *out_skb; struct sadb_msg *out_hdr; struct xfrm_state *x; @@ -1297,6 +1298,7 @@ return -ESRCH; out_skb = pfkey_xfrm_state2msg(x, 1, 3); + proto = x->id.proto; xfrm_state_put(x); if (IS_ERR(out_skb)) return PTR_ERR(out_skb); @@ -1304,7 +1306,7 @@ out_hdr = (struct sadb_msg *) out_skb->data; out_hdr->sadb_msg_version = hdr->sadb_msg_version; out_hdr->sadb_msg_type = SADB_DUMP; - out_hdr->sadb_msg_satype = pfkey_proto2satype(x->id.proto); + out_hdr->sadb_msg_satype = pfkey_proto2satype(proto); out_hdr->sadb_msg_errno = 0; out_hdr->sadb_msg_reserved = 0; out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; diff -ruN linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_policy.c linux-2.6.0-rc2-bk6/net/xfrm/xfrm_policy.c --- linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_policy.c 2004-01-09 12:42:53.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/xfrm/xfrm_policy.c 2004-01-09 17:31:05.000000000 -0800 @@ -694,6 +694,16 @@ static int stale_bundle(struct dst_entry *dst); +void dst_bundle_free(struct dst_entry *dst) +{ + struct dst_entry *next; + + while (dst) { + next = dst->child; + dst_free(dst); + } +} + /* Main function: finds/creates a bundle for given flow. * * At the moment we eat a raw IP route. Mostly to speed up lookups @@ -799,9 +809,16 @@ goto restart; } } - if (err) + if (err < 0) goto error; - } else if (nx == 0) { + /* + * Save number of xfrm_state's found/created for both + * the nx == 0 check below as well as to pass the + * right value to xfrm_bundle_create(). + */ + nx = err; + } + if (nx == 0) { /* Flow passes not transformed. */ xfrm_pol_put(policy); return 0; @@ -827,8 +844,8 @@ write_unlock_bh(&policy->lock); xfrm_pol_put(policy); - if (dst) - dst_free(dst); + if (dst) /* 'dead' freed dst->next list only */ + dst_bundle_free(dst); goto restart; } dst->next = policy->bundles; diff -ruN linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_user.c linux-2.6.0-rc2-bk6/net/xfrm/xfrm_user.c --- linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_user.c 2004-01-09 12:57:42.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/xfrm/xfrm_user.c 2004-01-09 12:59:00.000000000 -0800 @@ -241,6 +241,7 @@ return x; error: + x->km.state = XFRM_STATE_DEAD; xfrm_state_put(x); error_no_put: *errp = err; From davem@pizda.ninka.net Fri Jan 9 20:54:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 20:54:47 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0A4sSTa022993 for ; Fri, 9 Jan 2004 20:54:29 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id UAA07194; Fri, 9 Jan 2004 20:48:10 -0800 Date: Fri, 9 Jan 2004 20:48:08 -0800 From: "David S. Miller" To: Krishna Kumar Cc: netdev@oss.sgi.com, krkumar@us.ibm.com, kumarkr@us.ibm.com Subject: Re: [PATCH] Bugs in xfrm Message-Id: <20040109204808.3db77be6.davem@redhat.com> In-Reply-To: References: <20031108223049.36651f8d.davem@redhat.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2320 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: 944 Lines: 28 On Fri, 9 Jan 2004 17:40:03 -0800 (PST) Krishna Kumar wrote: > These changes compile cleanly, but I couldn't test since these are > corner cases. Please let me know if this can be applied. I am sending > as one patch file for now instead of multiple files as they all small. Maybe you should actually try to test these changes before I think about applying them, for example: > +void dst_bundle_free(struct dst_entry *dst) > +{ > + struct dst_entry *next; > + > + while (dst) { > + next = dst->child; > + dst_free(dst); > + } > +} Explain to me how that won't loop forever if given a non-NULL dst? Next, this dst_bundle_free() thing is totally not needed as far as I can tell. When dst_free() is made, the top-level of the bundle's dst gets added to the garbage collection list, the garbage collection properly walks the children to process the whole bundle. Please redo this patch and please test it this time :) From davem@pizda.ninka.net Fri Jan 9 20:57:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 20:57:52 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0A4vdTa023398 for ; Fri, 9 Jan 2004 20:57:39 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id UAA07225; Fri, 9 Jan 2004 20:51:19 -0800 Date: Fri, 9 Jan 2004 20:51:19 -0800 From: "David S. Miller" To: Michal Ludvig Cc: netdev@oss.sgi.com Subject: Re: [PATCH] sha2-256 truncation Message-Id: <20040109205119.71482788.davem@redhat.com> In-Reply-To: <3FFE7E98.6060201@logix.cz> References: <3FFE6B72.9030808@logix.cz> <3FFE7E98.6060201@logix.cz> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2321 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: 584 Lines: 15 On Fri, 09 Jan 2004 11:12:40 +0100 Michal Ludvig wrote: > Michal Ludvig told me that: > > > the attached trivial patch corrects the truncation size of computed > > hashes that are used in IPsec ESP/AH packets for SHA2-256. All other > > hash algorithms use 96 bits as well as does SuperFreeS/WAN and FreeBSD > > also for SHA2-256. Only the native Linux sha2-256 used 128 bits what led > > to incompatibility with other IPsec implementations. > > Oops, sorry. I sent a reversed patch originally. Please use this one > instead. Patch applied, thanks Michal. From rask@sygehus.dk Sat Jan 10 04:14:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jan 2004 04:14:50 -0800 (PST) Received: from 0x50a17250.albnxx15.adsl-dhcp.tele.dk (0x50a144d5.albnxx15.adsl-dhcp.tele.dk [80.161.68.213]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0ACEMTa006942 for ; Sat, 10 Jan 2004 04:14:23 -0800 Received: by 0x50a17250.albnxx15.adsl-dhcp.tele.dk (Postfix, from userid 500) id C5BFF19308; Sat, 10 Jan 2004 00:33:07 +0100 (CET) Date: Sat, 10 Jan 2004 00:33:07 +0100 From: Rask Ingemann Lambertsen To: netdev@oss.sgi.com, linux-net@vger.kernel.org Cc: jgarzik@pobox.com Subject: [PATCH] [EXPERIMENTAL] 2.6: de2104x.c jumbo frames, take two Message-ID: <20040110003304.A3788@sygehus.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 2324 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rask@sygehus.dk Precedence: bulk X-list: netdev Content-Length: 996 Lines: 26 Hi. Attached is a patch which enables jumbo frames on DS2104x based boards. The maximum supported MTU is 4066 bytes (but see below). Room for a VLAN tag is included. The maximum supported MTU is about twice as large as in my first jumbo frame patch because both buffers of RX and TX descriptors are used (just like the winbond-840 driver on TX). The media tables have been adjusted to disable the RX watchdog and TX jabber timers. Tested with a DS21041 and an MTU of 3544 on BNC media with an NE3200 board at the other end without problems. Known bugs and problems: 1. Although the DS21143 manual says that the RX frame descriptor size field is 14 bits wide, the DS21041 seems to use only 11 bits. This means that frames larger than 1518+2048 bytes can not be told apart from frames larger than 1518 bytes but smaller than 2048 bytes. As a result, setting the MTU larger than 3544 will cause problems. Please report success or failure with this patch. -- Regards, Rask Ingemann Lambertsen From rask@sygehus.dk Sat Jan 10 05:47:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jan 2004 05:47:56 -0800 (PST) Received: from 0x50a144d5.albnxx15.adsl-dhcp.tele.dk (0x50a144d5.albnxx15.adsl-dhcp.tele.dk [80.161.68.213]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0ADldTa011772 for ; Sat, 10 Jan 2004 05:47:40 -0800 Received: by 0x50a17250.albnxx15.adsl-dhcp.tele.dk (Postfix, from userid 500) id B324819E7B; Sat, 10 Jan 2004 14:47:38 +0100 (CET) Date: Sat, 10 Jan 2004 14:47:38 +0100 From: Rask Ingemann Lambertsen To: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: [PATCH] [EXPERIMENTAL] 2.6: de2104x.c jumbo frames, take two Message-ID: <20040110144738.A1385@sygehus.dk> References: <20040110003304.A3788@sygehus.dk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040110003304.A3788@sygehus.dk>; from rask@sygehus.dk on Sat, Jan 10, 2004 at 12:33:07AM +0100 X-archive-position: 2325 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rask@sygehus.dk Precedence: bulk X-list: netdev Content-Length: 6944 Lines: 211 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jan 10, 2004 at 12:33:07AM +0100, Rask Ingemann Lambertsen wrote: > Hi. > > Attached is a patch which enables jumbo frames on DS2104x based boards. And then I forgot to include the patch. :-( Regards, Rask Ingemann Lambertsen --zhXaljGHf11kAtnf Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="de2104x-mtu.patch" Content-Transfer-Encoding: 8bit --- linux-2.6.0/drivers/net/tulip/de2104x.c-før-mtu Sun Dec 21 14:31:04 2003 +++ linux-2.6.0/drivers/net/tulip/de2104x.c Mon Jan 5 02:01:15 2004 @@ -19,7 +19,6 @@ like dl2k.c/sundance.c * Constants (module parms?) for Rx work limit * Complete reset on PciErr - * Jumbo frames / dev->change_mtu * Adjust Rx FIFO threshold and Max Rx DMA burst on Rx FIFO error * Adjust Tx FIFO threshold and Max Tx DMA burst on Tx FIFO error * Implement Tx software interrupt mitigation via @@ -36,6 +35,7 @@ #include #include #include +#include #include #include #include @@ -67,11 +67,15 @@ static int debug = -1; MODULE_PARM (debug, "i"); MODULE_PARM_DESC (debug, "de2104x bitmapped message enable number"); +/* Each descriptor has two buffers. */ +#define DESC_BUF_SZ_MAX 2044 +#define PKT_BUF_SZ_MAX 4088 /* Maximum Rx buffer size. */ + /* Set the copy breakpoint for the copy-only-tiny-buffer Rx structure. */ #if defined(__alpha__) || defined(__arm__) || defined(__hppa__) \ || defined(__sparc_) || defined(__ia64__) \ || defined(__sh__) || defined(__mips__) -static int rx_copybreak = 1518; +static int rx_copybreak = PKT_BUF_SZ_MAX; #else static int rx_copybreak = 100; #endif @@ -356,12 +360,12 @@ static const char * const media_name[DE_ * TP AUTO(unused), BNC(unused), AUI, TP, TP FD*/ static u16 t21040_csr13[] = { 0, 0, 0x8F09, 0x8F01, 0x8F01, }; static u16 t21040_csr14[] = { 0, 0, 0x0705, 0xFFFF, 0xFFFD, }; -static u16 t21040_csr15[] = { 0, 0, 0x0006, 0x0000, 0x0000, }; +static u16 t21040_csr15[] = { 0, 0, 0x0017, 0x0011, 0x0011, }; /* 21041 transceiver register settings: TP AUTO, BNC, AUI, TP, TP FD*/ static u16 t21041_csr13[] = { 0xEF01, 0xEF09, 0xEF09, 0xEF01, 0xEF09, }; static u16 t21041_csr14[] = { 0xFFFF, 0xF7FD, 0xF7FD, 0x6F3F, 0x6F3D, }; -static u16 t21041_csr15[] = { 0x0008, 0x0006, 0x000E, 0x0008, 0x0008, }; +static u16 t21041_csr15[] = { 0x0019, 0x0017, 0x001F, 0x0019, 0x0019, }; static inline unsigned long @@ -374,6 +378,12 @@ msec_to_jiffies(unsigned long ms) #define dr32(reg) readl(de->regs + (reg)) #define dw32(reg,val) writel((val), de->regs + (reg)) +static inline u32 opts2_sizes (uint total_size) +{ + if (total_size <= DESC_BUF_SZ_MAX) + return (total_size); + return (((total_size - DESC_BUF_SZ_MAX) << 11) | DESC_BUF_SZ_MAX); +} static void de_rx_err_acct (struct de_private *de, unsigned rx_tail, u32 status, u32 len) @@ -422,7 +432,9 @@ static void de_rx (struct de_private *de if (status & DescOwn) break; - len = ((status >> 16) & 0x7ff) - 4; + len = ((status >> 16) & 0x3fff) - 4; + if ((len <= 1514) && (status & RxErrLong)) + len += 2048; mapping = de->rx_skb[rx_tail].mapping; if (unlikely(drop)) { @@ -430,7 +442,7 @@ static void de_rx (struct de_private *de goto rx_next; } - if (unlikely((status & 0x38008300) != 0x0300)) { + if (unlikely((status & 0x38004b53) != 0x0300)) { de_rx_err_acct(de, rx_tail, status, len); goto rx_next; } @@ -483,11 +495,13 @@ static void de_rx (struct de_private *de rx_next: de->rx_ring[rx_tail].opts1 = cpu_to_le32(DescOwn); if (rx_tail == (DE_RX_RING_SIZE - 1)) - de->rx_ring[rx_tail].opts2 = - cpu_to_le32(RingEnd | de->rx_buf_sz); + de->rx_ring[rx_tail].opts2 = cpu_to_le32( + RingEnd | opts2_sizes (de->rx_buf_sz)); else - de->rx_ring[rx_tail].opts2 = cpu_to_le32(de->rx_buf_sz); + de->rx_ring[rx_tail].opts2 = cpu_to_le32( + opts2_sizes (de->rx_buf_sz)); de->rx_ring[rx_tail].addr1 = cpu_to_le32(mapping); + de->rx_ring[rx_tail].addr2 = cpu_to_le32(mapping + DESC_BUF_SZ_MAX); rx_tail = NEXT_RX(rx_tail); } @@ -632,9 +646,10 @@ static int de_start_xmit (struct sk_buff flags |= RingEnd; if (!tx_free || (tx_free == (DE_TX_RING_SIZE / 2))) flags |= TxSwInt; - flags |= len; + flags |= opts2_sizes (len); txd->opts2 = cpu_to_le32(flags); txd->addr1 = cpu_to_le32(mapping); + txd->addr2 = cpu_to_le32(mapping + DESC_BUF_SZ_MAX); de->tx_skb[entry].skb = skb; de->tx_skb[entry].mapping = mapping; @@ -770,6 +785,7 @@ static void __de_set_rx_mode (struct net dummy_txd->opts2 = (entry == (DE_TX_RING_SIZE - 1)) ? cpu_to_le32(RingEnd) : 0; dummy_txd->addr1 = 0; + dummy_txd->addr2 = 0; /* Must set DescOwned later to avoid race with chip */ @@ -788,6 +804,7 @@ static void __de_set_rx_mode (struct net else txd->opts2 = cpu_to_le32(SetupFrame | sizeof (de->setup_frame)); txd->addr1 = cpu_to_le32(mapping); + txd->addr2 = cpu_to_le32(0); wmb(); txd->opts1 = cpu_to_le32(DescOwn); @@ -1277,7 +1294,9 @@ static int de_init_hw (struct de_private static int de_refill_rx (struct de_private *de) { unsigned i; + u32 opts2; + opts2 = opts2_sizes (de->rx_buf_sz); for (i = 0; i < DE_RX_RING_SIZE; i++) { struct sk_buff *skb; @@ -1294,11 +1313,11 @@ static int de_refill_rx (struct de_priva de->rx_ring[i].opts1 = cpu_to_le32(DescOwn); if (i == (DE_RX_RING_SIZE - 1)) de->rx_ring[i].opts2 = - cpu_to_le32(RingEnd | de->rx_buf_sz); + cpu_to_le32(RingEnd | opts2); else - de->rx_ring[i].opts2 = cpu_to_le32(de->rx_buf_sz); + de->rx_ring[i].opts2 = cpu_to_le32(opts2); de->rx_ring[i].addr1 = cpu_to_le32(de->rx_skb[i].mapping); - de->rx_ring[i].addr2 = 0; + de->rx_ring[i].addr2 = cpu_to_le32(de->rx_skb[i].mapping + DESC_BUF_SZ_MAX); } return 0; @@ -1386,6 +1405,8 @@ static int de_open (struct net_device *d printk(KERN_DEBUG "%s: enabling interface\n", dev->name); de->rx_buf_sz = (dev->mtu <= 1500 ? PKT_BUF_SZ : dev->mtu + 32); + if (de->rx_buf_sz > PKT_BUF_SZ_MAX) + de->rx_buf_sz = PKT_BUF_SZ_MAX; rc = de_alloc_rings(de); if (rc) { @@ -1476,6 +1497,18 @@ static void de_tx_timeout (struct net_de netif_wake_queue(dev); } +static int de_change_mtu (struct net_device *dev, int mtu) +{ + if (netif_running (dev)) + return (-EBUSY); + + if (mtu < 0 || mtu > PKT_BUF_SZ_MAX - VLAN_ETH_HLEN - 4) + return (-EINVAL); + + dev->mtu = mtu; + return (0); +} + static void __de_get_regs(struct de_private *de, u8 *buf) { int i; @@ -1980,6 +2013,7 @@ static int __devinit de_init_one (struct dev->ethtool_ops = &de_ethtool_ops; dev->tx_timeout = de_tx_timeout; dev->watchdog_timeo = TX_TIMEOUT; + dev->change_mtu = de_change_mtu; dev->irq = pdev->irq; --zhXaljGHf11kAtnf-- From kumarkr@us.ibm.com Sat Jan 10 10:34:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jan 2004 10:34:47 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0AIYRTa023287 for ; Sat, 10 Jan 2004 10:34:33 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0AIYLrE106950; Sat, 10 Jan 2004 13:34:21 -0500 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0AIYJjd142510; Sat, 10 Jan 2004 11:34:20 -0700 Subject: Re: [PATCH] Bugs in xfrm To: "David S. Miller" Cc: krkumar@us.ibm.com, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Krishna Kumar Date: Sat, 10 Jan 2004 10:33:22 -0800 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/10/2004 11:34:20 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE484DFCD6FFA8f9e8a93df938690918c07BBE484DFCD6FFA" Content-Disposition: inline X-archive-position: 2326 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2475 Lines: 61 --0__=07BBE484DFCD6FFA8f9e8a93df938690918c07BBE484DFCD6FFA Content-type: text/plain; charset=US-ASCII > Explain to me how that won't loop forever if given a non-NULL dst? Oops, forgot the dst = next in the loop :-) > Next, this dst_bundle_free() thing is totally not needed as far as I can > tell. When dst_free() is made, the top-level of the bundle's dst gets added > to the garbage collection list, the garbage collection properly walks the > children to process the whole bundle. The garbage collector (called via __dst_free) takes dst_garbage_list and goes through the dst->next pointer. But dst_destroy() seems to destroy stuff on the dst->child list (I missed the part that the first dst has a refcnt of zero and all others on child have refcnt of 1). So this is not needed. > Please redo this patch and please test it this time :) Are the other "bugs" correct :-) Or should I send separate patches this time ? thanks, - KK --0__=07BBE484DFCD6FFA8f9e8a93df938690918c07BBE484DFCD6FFA Content-type: text/html; charset=US-ASCII Content-Disposition: inline

> Explain to me how that won't loop forever if given a non-NULL dst?

Oops, forgot the dst = next in the loop :-)

> Next, this dst_bundle_free() thing is totally not needed as far as I can
> tell. When dst_free() is made, the top-level of the bundle's dst gets added
> to the garbage collection list, the garbage collection properly walks the
> children to process the whole bundle.

The garbage collector (called via __dst_free) takes dst_garbage_list and
goes through the dst->next pointer. But dst_destroy() seems to destroy stuff
on the dst->child list (I missed the part that the first dst has a refcnt of
zero and all others on child have refcnt of 1). So this is not needed.

> Please redo this patch and please test it this time :)

Are the other "bugs" correct :-) Or should I send separate patches this time ?

thanks,

- KK
--0__=07BBE484DFCD6FFA8f9e8a93df938690918c07BBE484DFCD6FFA-- From davem@pizda.ninka.net Sat Jan 10 12:17:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jan 2004 12:18:13 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0AKHx6H026789 for ; Sat, 10 Jan 2004 12:17:59 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA21517; Sat, 10 Jan 2004 12:11:34 -0800 Date: Sat, 10 Jan 2004 12:11:34 -0800 From: "David S. Miller" To: Krishna Kumar Cc: krkumar@us.ibm.com, netdev@oss.sgi.com Subject: Re: [PATCH] Bugs in xfrm Message-Id: <20040110121134.08481951.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2327 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: 162 Lines: 6 On Sat, 10 Jan 2004 10:33:22 -0800 Krishna Kumar wrote: > Or should I send separate patches this time ? I think this would be a good idea. From jgarzik@pobox.com Sat Jan 10 17:16:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jan 2004 17:17:19 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0B1Gw6H007754 for ; Sat, 10 Jan 2004 17:16:59 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:34253 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AfUDp-0005MQ-8s; Sun, 11 Jan 2004 01:16:57 +0000 Message-ID: <4000A3F0.9070701@pobox.com> Date: Sat, 10 Jan 2004 20:16:32 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] bugfixes for dgrs.c References: <20040108165343.7ed94da9@linux.local> In-Reply-To: <20040108165343.7ed94da9@linux.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2329 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 Content-Length: 10 Lines: 3 applied From jgarzik@pobox.com Sat Jan 10 17:16:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jan 2004 17:16:28 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0B1GE6H007728 for ; Sat, 10 Jan 2004 17:16:15 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:34252 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AfUD6-0005MB-HI; Sun, 11 Jan 2004 01:16:12 +0000 Message-ID: <4000A3C3.3040709@pobox.com> Date: Sat, 10 Jan 2004 20:15:47 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: netdev@oss.sgi.com, mikep@linuxtr.net.sgi.com, linux-tr@linuxtr.net.sgi.com Subject: Re: [PATCH] Mark IBM TR driver as not 64 bit clean References: <20040109090908.GA1772@averell> In-Reply-To: <20040109090908.GA1772@averell> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2328 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 Content-Length: 17 Lines: 3 applied to 2.6 From jgarzik@pobox.com Sat Jan 10 17:50:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jan 2004 17:50:27 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0B1oD6H009169 for ; Sat, 10 Jan 2004 17:50:13 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:34270 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AfUk0-0005aM-0i; Sun, 11 Jan 2004 01:50:12 +0000 Message-ID: <4000ABBA.50601@pobox.com> Date: Sat, 10 Jan 2004 20:49:46 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Olsson CC: Greg Banks , "David S. Miller" , Linux Network Development list Subject: Re: [PATCH] make tg3 NAPI support configurable References: <3FE2F3A7.2A109F28@melbourne.sgi.com> <16354.64258.364153.488309@robur.slu.se> In-Reply-To: <16354.64258.364153.488309@robur.slu.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2330 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 Content-Length: 1354 Lines: 35 Robert Olsson wrote: > Greg Banks writes: > > > I've been having some issues with irq rates and cpu usage in the > > tg3 driver. In short, on Altix machines they're far too high. > > It turned out that reverting the driver to its pre-NAPI interrupt > > coalescing scheme made the situation a lot better. > > > > How much better? Running 8192 byte UDP packets across gige > > with NAPI takes 99.5% of a CPU to service 29,100 irqs per second. > > With the pre-NAPI code the figures are 36.0% CPU and 4880 irq/sec. > > Similar improvements are seen for non-fragmented UDP and for TCP. > > Hello! > > You can use coalescing with NAPI as well, e1000 and other drivers > are doing this. This will give you same interrupt rates as non- > NAPI at low load and "polling" without any interrupts at high load. Yes, this is something I've been meaning to add to tg3 for months now. Adding some about of hardware intr mitigation -in addition to- NAPI will not only help on the NAPI "hard case" of moderate load and a super-fast CPU, but also help avoid certain silicon bugs... > Furthermore NAPI can be extended to schedule dev->poll even for TX- > interrupts. There is pacth for e1000 doing this. We see about 5-8% > overall system packet improvement with this. tg3 already schedules for TX, so we've got that part covered :) Jeff From jgarzik@pobox.com Sat Jan 10 19:40:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jan 2004 19:41:09 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0B3ek6H011767 for ; Sat, 10 Jan 2004 19:40:47 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:34377 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AfWSz-0006HI-Eb; Sun, 11 Jan 2004 03:40:45 +0000 Message-ID: <4000C5A3.5070101@pobox.com> Date: Sat, 10 Jan 2004 22:40:19 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux Kernel , Netdev CC: Andrew Morton Subject: [NETDEV] experimental net driver queue updated Content-Type: multipart/mixed; boundary="------------010204090309070907070407" X-archive-position: 2331 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 Content-Length: 5279 Lines: 148 This is a multi-part message in MIME format. --------------010204090309070907070407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The 250+ patch queue was getting way too big to manage, so using BK I split things up locally into a number of buckets. This allowed me to much more easily digest Al Viro's latest patch flood, as well as get things into much better shape for submission to upstream (as soon as the tree re-opens)... some changes were definitely more experimental than others, and won't go to Andrew/upstream until bugs and interface issues are fully sorted out. This split-up allowed me to easily create broken-out sets of patches, which are available at the URL below. Note the new "netdev" moniker too, that's not a typo. Summary of new changes: * forcedeth update * more fixes and cleanups from Al Viro * netpoll, atmel, dgrs updates * other bits Summary of patchkit: * new e100 driver (rewritten from scratch) * new nVidia nForce NIC driver * new pci200syn WAN driver * r8169 major bug fixes * e1000 minor updates / fixes * sk98lin vendor updates / fixes * many bonding updates and cleanups * misc bug fixes * 8139too NAPI support * tulip NAPI support * netconsole / netdump support * net_device allocation and reference counting work Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev2.patch.bz2 Full changelog: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev2.log Broken-out patches (broken out into "buckets" not changesets): http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/broken-out/ BK repo: bk://gkernel.bkbits.net/netdev-2.6 or http://gkernel.bkbits.net/netdev-2.6 Changelog delta attached. --------------010204090309070907070407 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="changelog.txt" Alexander Viro: o [wan pci200syn] eliminate embedded hdlc_device struct o [netdrvr s390/qeth] Alloc fixes o [netdrvr shaper] fix double-free o [netdrvr dvb/dvb_net] fixes o [netdrvr arch/uml] leak fix o [netdrvr saa9730] fix double-free o [netdrvr arm/am79c961] Fix for IO-before-request_region race o [wan] leak fixes in hostess_sv11, lapbether o [netdrvr s390/lcs] Leak fix o [wireless orinoco] check alloc_etherdev for failure o [netdrvr apne] resource leak fix o [netdrvr 3c509] Leak fixed o [netdrvr acenic] Race and leak fixes o [all over] more kfree -> free_netdev o [netdrvr isa-skeleton] cleanups and fixes o [wan sdla] Fixed leaks and double-free o [netdrvr fec] switched to sane allocation. It still leaks on failure exits, though o [netdrvr s390/netiucv] partially sanitized wrt allocation o [wireless airo] switched to sane allocation o [netdrvr tun] Killed bogus ->init() o [wan sealevel] Plugged a leak o [wan sbni] sane net_device allocation; plug a bunch of leaks o [wan hostess_sv11] sane net_device allocation o [wan hdlc_fr] Switched allocation of net_device to alloc_netdev() o [wan hdlc] kill embedding of struct net_device o [wan hdlc] removal hdlc_to_dev() o [wan dscc4] embedded struct removal o [wan farsync] embedded struct hdlc_device removal o [wan pc300] use alloc_hdlcdev()/free_hdlcdev(). Leak fixed o [wan hdlc] kill embedded struct in various drivers o [wan hdlc] new private struct pointer in hdlc_device, and helpers for it o [wan hdlc] switch register_hdlc_device() to take net_device arg o [wan dscc4] Uses of ->hdlc and hdlc_to_dev() encapsulated into dscc4_to_dev() o [wan hdlc] new hdlc_stats() helper o [wan pc300] more direct use of net_device o [wan hdlc] switch internal ioctl dispatch to net_device o [wan wanxl] eliminated hdlc_to_name() uses and a bunch of port->hdlc ones o [wan hdlc_x25] eliminated hdlc_to_dev() and hdlc_to_name() uses o [wan hdlc] hdlc_fr: eliminated ->netdev, hdlc_to_dev() and hdlc_to_name() uses o [wan hdlc] hdlc_cisco: killed ->netdev, hdlc_to_name() and hdlc_to_dev() uses o [wan hdlc] hdlc->proto.*() switched to net_device o [wan farsync] Eliminated a bunch of port->hdlc and hdlc_to_dev() uses o [wan hdlc] hdlc->attach() switched to net_device o [wan hdlc] hdlc_set_carrier() switched to net_device o [wan hdlc] switch sca_xxx() to use net_device o [wan hdlc] new port_to_dev() helper o [wan hdlc] hdlc_close() switched to net_device o [wan hdlc] hdlc_open() switched to net_device o [wan lapb] kill now-unused custom token container o [wan lapb] Printks switched from %p lapb->token to %p lapb->dev o [wan lapb] switch to use net_device instead of custom token o [wan lapb] beginning of cleanups Andi Kleen: o Mark IBM TR driver as not 64 bit clean Jeff Garzik: o [tokenring olympic] use memset_io to fix certain platforms Manfred Spraul: o [netdrvr forcedeth] alloc fixes Matt Mackall: o netpoll carrier handling o netconsole init return code o netconsole init return code o [netdrvr] add netpoll support to several 8390-based drivers o netpoll abort for bad interface Simon Kelley: o [wireless atmel] various updates Stephen Hemminger: o bugfixes for dgrs.c --------------010204090309070907070407-- From jgarzik@pobox.com Sun Jan 11 00:24:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 00:24:32 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0B8O86H025384 for ; Sun, 11 Jan 2004 00:24:11 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:34680 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AfatC-00022h-Vb; Sun, 11 Jan 2004 08:24:07 +0000 Message-ID: <4001080D.3090401@pobox.com> Date: Sun, 11 Jan 2004 03:23:41 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dpollock@acm.org CC: Francois Romieu , netdev@oss.sgi.com Subject: Re: Realtek 8169 Lock-ups References: <1073507006.5151.61.camel@localhost> <20040107232034.A22930@electric-eye.fr.zoreil.com> <1073596694.6378.6.camel@localhost> In-Reply-To: <1073596694.6378.6.camel@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2333 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 Content-Length: 277 Lines: 16 Hum... where are we on this? Francois made a few key fixes before he left, which I've included in the latest netdev patch... http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev2.patch.bz2 Have those already been tested? Thanks, Jeff From akpm@osdl.org Sun Jan 11 00:45:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 00:45:57 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0B8ji6H026232 for ; Sun, 11 Jan 2004 00:45:44 -0800 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0B8jZo00742; Sun, 11 Jan 2004 00:45:35 -0800 Date: Sun, 11 Jan 2004 00:45:40 -0800 From: Andrew Morton To: Jeff Garzik Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [NETDEV] experimental net driver queue updated Message-Id: <20040111004540.403ca854.akpm@osdl.org> In-Reply-To: <4000C5A3.5070101@pobox.com> References: <4000C5A3.5070101@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: 2334 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: 797 Lines: 23 Jeff Garzik wrote: > > Patch: > http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev2.patch.bz2 net/core/netpoll.c: In function `netpoll_setup': net/core/netpoll.c:572: warning: too many arguments for format net/core/netpoll.c:572: warning: too many arguments for format --- 25/net/core/netpoll.c~netpoll-warning-fix 2004-01-11 00:43:24.000000000 -0800 +++ 25-akpm/net/core/netpoll.c 2004-01-11 00:43:50.000000000 -0800 @@ -569,7 +569,7 @@ int netpoll_setup(struct netpoll *np) if (time_before(jiffies, atleast)) { printk(KERN_NOTICE "%s: carrier detect appears flaky," " waiting 10 seconds\n", - np->name, np->dev_name); + np->name); while (time_before(jiffies, atmost)) cond_resched(); } _ From romieu@fr.zoreil.com Sun Jan 11 03:53:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 03:53:25 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BBr96H001215 for ; Sun, 11 Jan 2004 03:53:11 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0BBo8sW018807; Sun, 11 Jan 2004 12:50:08 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0BBnwiI018801; Sun, 11 Jan 2004 12:49:58 +0100 Date: Sun, 11 Jan 2004 12:49:57 +0100 From: Francois Romieu To: Jeff Garzik Cc: dpollock@acm.org, netdev@oss.sgi.com, damouse@ntlworld.com, brad@mainstreetsoftworks.com, kinetik@orcon.net.nz Subject: Re: Realtek 8169 Lock-ups Message-ID: <20040111124957.A18068@electric-eye.fr.zoreil.com> References: <1073507006.5151.61.camel@localhost> <20040107232034.A22930@electric-eye.fr.zoreil.com> <1073596694.6378.6.camel@localhost> <4001080D.3090401@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4001080D.3090401@pobox.com>; from jgarzik@pobox.com on Sun, Jan 11, 2004 at 03:23:41AM -0500 X-Organisation: Land of Sunshine Inc. X-archive-position: 2335 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1568 Lines: 43 Jeff Garzik : [...] > Have those already been tested? Yes. Tester (damouse) included in Cc: list. The patches improves the situation so that it is possible to bring the interface up and send/receive traffic but something clearly smashes the stack (if someone wants to check, .jpg panic and r8169 module available at http://www.fr.zoreil.com/people/francois/misc/debug). After the latest days of "patch/patch -R/change line foo into bar/...", I have rediffed the whole serie of changes against 2.6.1 so M. Damouse can test an identified set of patches and isolate the misbehaving one(s). It is available at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.1. If people can reproduce the tests that M. Damouse made, it should look like: apply r8169-dma-api-tx.patch apply r8169-dma-api-rx-buffers.patch apply r8169-dma-api-rx-buffers-ahum.patch apply r8169-rx-fill-typo.patch apply r8169-start-xmit-fixes.patch apply r8169-dma-api-tx-buffers.patch apply r8169-rx_copybreak.patch -> So far, so good, no regression from classical driver apply r8169-mac-phy-version.patch apply r8169-buggy-devinitdata.patch -> Seems fine but panics after a few ko of traffic Confirmation, anyone ? The set contains two extra/untested patches [*] wrt 2.6.1-bk1-netdev2. No need to push these further until the current issues are fixed imho. M. Pollock's problems look different: - they do not depend on the driver used; - they seem timing/smp related (mobile computer + p4 HT). [*] r8169-addr-high.patch r8169-ethtool-introduction.patch -- Ueimor From damouse@ntlworld.com Sun Jan 11 05:57:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 05:58:06 -0800 (PST) Received: from mta02-svc.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BDvq6H016974 for ; Sun, 11 Jan 2004 05:57:53 -0800 Received: from EozVul.WORKGROUP ([217.137.146.80]) by mta02-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with SMTP id <20040111135725.DALH17535.mta02-svc.ntlworld.com@EozVul.WORKGROUP>; Sun, 11 Jan 2004 13:57:25 +0000 Date: Sun, 11 Jan 2004 13:59:00 +0000 From: DaMouse Networks To: Francois Romieu Cc: netdev@oss.sgi.com Subject: Re: [BUG] 2.6.1-rc1-mm1 with r8169 driver Message-Id: <20040111135900.1acb95b3@EozVul.WORKGROUP> In-Reply-To: <20040111141806.A19535@electric-eye.fr.zoreil.com> References: <20040106214950.6901a5a1@EozVul.WORKGROUP> <20040106232646.E4767@electric-eye.fr.zoreil.com> <20040110153709.0df74309@EozVul.WORKGROUP> <20040110213531.C4413@electric-eye.fr.zoreil.com> <20040110210058.74e4fbca@EozVul.WORKGROUP> <20040110224439.E4413@electric-eye.fr.zoreil.com> <20040110215315.73d8953b@EozVul.WORKGROUP> <20040110231546.F4413@electric-eye.fr.zoreil.com> <20040111000920.A7396@electric-eye.fr.zoreil.com> <20040111125428.7dfc6d54@EozVul.WORKGROUP> <20040111141806.A19535@electric-eye.fr.zoreil.com> Organization: DaMouse Networks X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sun__11_Jan_2004_13_59_00_+0000__w4ZBaR2oW0h.mhe" X-archive-position: 2336 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: damouse@ntlworld.com Precedence: bulk X-list: netdev Content-Length: 10475 Lines: 163 This is a multi-part message in MIME format. --Multipart=_Sun__11_Jan_2004_13_59_00_+0000__w4ZBaR2oW0h.mhe Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Same results for non-SMP kernel (kpanic after a few minutes of surfing and also when i ran ping -f). Stock 2.6.1 runs fine with my 7000 (ping -f) packets to the router :). debug-stuff for 2.6.1-r8169 (2.6.1+the r8169 that we've applied so far) is attached. -DaMouse On Sun, 11 Jan 2004 14:18:06 +0100 Francois Romieu wrote: > DaMouse Networks : > > Ok, looks like my additional testing with ping -f is bringing out the bugs > > in this baby, once I'd got past the r8169-rx-fill-typo.patch it borked on > > "ping -f" with the kpanic I pictured last time. Looks like I shoulda tested > > that also last time :/. I have attached the files you requested any other > > stuff you need just ask :) > > Fine. I'll dig it this evening. > > (/me gives a quick sight...) > > Hmmm... acpi + HT smp. > > Can you (no more request until I cook something, no joke :o) ): > - check that plain 2.6.1 driver does not panic under 'ping -f' ? > - compile a non SMP enabled kernel and see if patched r8169 is stable > - during normal traffic > - during 'ping -f' > > Please Cc: netdev@oss.sgi.com and include the relevant 'dmesg' output. > > -- > Ueimor --Multipart=_Sun__11_Jan_2004_13_59_00_+0000__w4ZBaR2oW0h.mhe Content-Type: application/octet-stream; name="debug.tar.bz2" Content-Disposition: attachment; filename="debug.tar.bz2" Content-Transfer-Encoding: base64 QlpoOTFBWSZTWSpHEcAAF97/j//diEB6///7f///zv////ACAAAAgAgAIAAIYBzePPHq7766mu3O wD19A6B7a2PWHVe2Nzd7G9m6Hp113Xcdz5vvtZjr6fI77upvYD6+vJewA6evp9dGvkHQHpkVc93T RoB8JRBAAE0aaBNMRonomlPyaTwIEhtTQGg9IeoDQAlCAE0CCaCp/kpspsqe1TanqYjyj1NANAfq QNA02oaZDIJQEEKGmmmRT21SbU9qI2p6QAaANDRoBoANAAAk1IiaGmqnqep+hE8psoD1AB6gBkAA AAAAACJKJNpIHoQzU00AZpA0AAaANADEAAAAkRCATQTCCMIRkp+mk2p6iZPGpNGamj0nqBkAABp8 0yf99Nk1/XxEvX0vlSABLkVbXG6elohbnqIYTISARKFbCi9p2JaDdFpAiVB49CUsUSxLiWCwqJUE lLRUCEUVYSIhBTDZa3fD+nmWsbDAlH0nChpl431eQdWzXs6rCqqqtHImSFqrObodfXUw5cePeXtf Xx1TZWyBrUSynAtnIdOZxtreBwM/xd8JbS+hsb08PDU8HJJh8ljvApazLNYo9dNRp2eGlr9/Nu3O f3afW1b+/xg3Wazw/Nm7Nn18caW3lOAXXWfRvUyi3AtZeDrYUhAN9UEkohIvvb5918Knvc+2Y1oM vqaDklsV8U6M8NJlPIyd3yNGWEcrs+ypgu9vLGtWdbvUX9dGL3bpoz6lyZ6Y6XotnSwZmZmnqvfd z5eaUqs17bqr3kfoXzrQltkg73EGQRG8EC2goVAykioH04VKiPDg3kMEDAQNCWnf7lP9gVF2F/od 9wQKt0Ef7cpGtiuMkFeVr0R6Zs7Bsy5fRUgPUF/5phvz1USTXZJQBMw5wKFNd9N9EHBJNJBaiCrO l0RwVYrITYFs1Ol8MWgJfxv5LXkV7usxcv6meOBUwRrtuQiYb/p+Z6L3+qp6kDpmOB+V1wH35np0 lt4ftMM7tLT29z58PD3crWTr5dTrROX1/5e0FShib8SUF3J0uXDuplBznVrs0GZnSpSmYEHzlNzE 1Ym03GnPqv+t6aIPPnU8V60QAwZcvzzyzFaBug1tKrbMuW+/TjQK1BTSfbQwFRRPmEc5VVVUeEVw ve9736ur5vV6Nb6Zpv+LNETm+iAyitKmQ3hK0NdWwbzdj2DS2XPLG1ou4cWpHgG3/PF5OZtj7m22 oGL6MRJzAq8Iql0F6iXxTUz2w8olElTsAMHw9rVWPOK3U9QFIl+kCYyx5+ujqTEtd/1bKUT+SeVr urfRvdkb7y/4dgd/NByiEKIgFEQBEzDbbfQP6eoY2C8Mse7SDt0iWbnDmYZn9fJGxtrQGsKA8rFu I2QkUQ1mjS2Q3gYyUyRQeGoTsbIoX9XrNQDqxZMBMGz+xn7cmxpEpkOlE09fi5Iq8y5kwQadP0yj RecalFKKrakz87AH3qZlFhNiDU9nC2LPfz4tx+PxooTad3HeoqmPgEtU6DUVQ7Kz2o+K7RExVZqr qdBBguvMOH9j/RNQEeYrdljZeHw1xR4z+cXOqXc/H7ZxH6Lb+tEVRDyn3eRDVXIYIChCtyBXrnHC Kkt7SkDOzzhvidOZxQIR3J478KIfvMph3MDW++umeeCerJBth9OrCgiTriXIUORCpTRgIUNOUcwz LKsYo6tgyXv/L5vElKp99N/Sy7iLXTL2IcQ0+ggyB6eppQOKgrnDdut0Bzt+m3bTUnErw7/QioM5 M7QpFSK7613qRVAN4syAxfAk526S70ZWLFzJjjzaTp8Fib66UtRYWzKs1RUERKcuxt4y09TQpRIM 19KdZpq7Jt+BR8pAqu7kpIxLfTU3m522ZGYw4w6WtoV8Ru+oNeWGeogM5nEuOP4wIQxUSt1/BnBV wix3yRFl3L6Im+DMWwZXn4mzEwZXmIH216DSvF6dhmm6h6zslqbi0vx9BEsWoNgWT8t+Q5yFpEZS 9gQID8SehiaJY7ZOPqopTYE7Fvyu5tTmWsPGyiL2gtpVNWY0n48gd1jPWzUtlzmiukJl8l2BgQmJ h5YyAsg87qSbVDmPPDZY8bu9JUuHScDq4i98TF+Gmjvs1IQKwtAdF22uJYGqQBRTtBxNCddmE3XH OLi+fW0SxKpG82JAlqVjzSnv75FV3V2jYk7btWz+WoJyte0NATPLIHBS7m539rc3GGVOE7sDbrZT kx5/9xbhBDMEm2GqxOrRz+5JAek4LNMyUiS8iVr92v0UOwfRL1IHW/R366Cc9nHhOlc3NWXKirQV 5ckRybcegmNhRSRcII0IF6YJpvdAat8hBnhZXLl4h3HvDBtwQFHDW80C5eR1tzB3tCAGtMRPIzkR +yPd9+DN/jP5b9JpFVUVNjOeHPy/D8bIMmANO5gGhoQAGrQfL/AT4efkU4kgG1ZtEe0OsZfcRGjn 5c1iKdkZk6Qb0+FiVZk2EH8YEZC4+npH9tfem6+rXmRNFmrRc3Pswzursgn0vzyzpBbi9Ieu9UPw T5JK2mRUONDwCORHR3oUx6Au6MVo2pQl8kfBNVxd95ETBZY/yfNt93PfdeJC4P52glrh9qMqQBPJ EST4Hts29Himemws2obhHxxNEm744/Z+LYiJ3Of679XfSboUZ9TBlG2WRj/OC9U4qYODmbndHFa1 CVUittxuREDiFNhRQ6RnuEmVEwUmmcaWMWfo0tQcsHOzmIcRwcVZaWmaA+DAwo1C8xNph2FCHkV0 IUIYe5zelWsYjA/DEzH2pZDJ8UoJOQ2UUjuX1wnbOmGn687mqq8yqH4gOJbqXiiqKI6mIEfs951j JFcz23FZOBu89Q/LSuT8CtZ7/VCh/mVY2PWUhfnEIaSgWvxgC6gCqApFpcgYy9bdJO7Uh/nuJESl tvvo1WEDjwa6mFRO6EejZAPwnBcClSVp8l9KHMv3cZq5Vo1jbw7o2nq2b/KvsTe8s8byLG1UcvbI kiII7AOUQwKoNvKdjEUaFEN8ZxziSt0pIRsL9mGzStJGCBpcB5nlKiG2CE0A4Wd2qouhsiMREQF0 AUaQoaS0DcoVIsRvgOslGZz5/L4ZDrMYsUFCbaWjdOLLMnFx5AFiQc5OfI9/8LQEem1MNgxXeprn JOJiQVcQze54uALOWamsEEO8QONJDSa8dAxjIrEkYJMd1qV67W6wrKynBTkDv3NF/leDvetqS0at Fkki/vEMSnHYad+P/OGMEQNpQkYX0i9jmETCmBbqROtpjEEkc6Kpl7dr2i8ETXcohiqU8Jeb2cWO eXH55JEkyVXNs5ILVTJs1thkYXcsLUDQIiYYp0RHnLTVu5GVW5IIwBQKseCWgQeZCFhLvalU39cd dU8kKic9gGP4SYT0qYRMm7K03iGG+IOppZOxEey1unrVDqK/w0/u4ROexui0TVrZsnxqirissvZP AI/JLtfbY+E5OgUwGZSrMG+LQUjVVyNzG6cpDsYF63VAw26ub3Z2YjMn7VKhmY0xGdZpK2mSCc6l wxiXs00itamEQCbaGXRAGj9NTGx0rcssLvDu9Wt7LZnwwM8b/Zctoxlf2kMZyLqmuEQXUjyZHk2X j3DTVRZqBMpJeEYR0n3E3SbzKblJlPIrhOSpBZIpIsgoooo8GNurdWosVQ2Os0dKOFJvqRMPg7Oh xyJC507YaNkYDbs8boY3Qhvu4w5hjbhYXzxRJGN3qQ99X0t/lzOtuVZ89afK/7WT1jRs0JoyrJNj IMKuNpJxgEqwyVHEpuaOLXeTrt0SNWQPfYjY02ZsMKWKcclVslKEXW6g6oJ8WjqC+CqbKJAdzdqa 1sddr+ypFbpBUlzJdydLUIfK+fDfy31Uvv0imLtzjb5qZacGFVRTDAMMzDNCaEIyTBayWU1ye8hz rRQHAei26k0dAUaND0lNnxm6xVM8Ns0L4aoyFLEzwyEmszav+KQuo92GjnYrR251W0C4lkfKJ1EP 2djoQMjGWSkKjS57OKza5IEFoOFP+N8I8ax3KEMwc1Xhko7FKZ5O0FPhg29mFOVOej1KnCSXe8SD PGVAiZ0aGKwlWbpR+F0+Iti3Cum3DM6cLPooz47q7CK12Ii0UoY0bmYncpNGlc1rvKyUXF09a7Ip g46VFWlYSVBHs0aWlF8LtzB61dK+WeFL4ZIPxb91WmmiRWr0jgjqy13jVjljk2WqpCiI+VFvELNY uO0eUzy8QloKmWGeJy1VfdZlIHmQ0ridP2NJGasfvKKCklgIRyD6onH3CQNwxzS5JsssDWMjUy3P 9S+HTtw3JeNsSYQQzo9kRTzcJ422zvGcHnjQirWXLPypO2ieSWJYxYggPhn+DPJ/cJDa3NTu5Mbb ro2+9/vuXxuG2y5tje8Ubs6VBUO5yaGvGhmqJTyVivLR4Plcu79F8YYh3mPKcinZP+L5RXB2uzo5 3elmOZZ3oyq7iKGNWKwjueiHQVvUeJLP1Bv2a7EDWskFSlSsJ4uCe1SSLe24RXtSVnCp44uwWf5i k762j717Wee1hrO1rMO0jvolU6X9F+edvDq7mUM8FLSMgZGBrokoAY0IKYngS2AAYiESkapfAuGg fKQUnyGS8mwZ91z02WsTjZhizj49gmettewtVPz9g/pQBI0P1nKikPzViDNko0/vrZ4foyc4O0Vq iuzoXNuO9DCZVvXKu1atv20tgMpS8VziCbgMnZ8ZapgNQaHE5zHSoC6AxTUwZAH3MO1E5FxQzazb H9KXNpVaOpoVDfFZWg12aCDAigaZJIGzCb2Ux96q09uqYS2hukNEjHISFAU9RmESITgZxTb/HKjn ZqGfDAZrdMZ/hOBT3hI9k72zBfZw4GRZXNtbTrCPLzQWs2iAlizS6bzJ9ioadzTu1A6bDTryipvJ QdDi2FHH6ToC2+OCQ7jeM50QwqqFhFFFkNBMEq94SzILBWIAc6SbOitQcr1+Dv54k4jsbM7WfsMD kzNr0iYEpF3iBM71AkQAM7AGZBSO9HmpqqFyaQwaF9b4e8+c6XhrJ28L2lWmN6+xl29Xg2lv6AXS dnqgR+n7oq/kYZ+N+ayOYORiza4sRq/vrPfbWpDNME1XDbnEWo6PWssU2KpMXDhQNF0zPSBuK0MC wNNe3yUAH7zQr6rm5ouEOF4Ae21zGMKGP865eVV51ZeyR20u4QTT8vZcSSHEVAHyQhIm5vfivom4 OYxJYSi4QjCAgYc0Avcco7w1DdPbcX2OIHZktqQdjElfeHW6M5gUSRQkHGjrjXNdgmKFiCkYQhCg sBB6elHapERDMTSUXal1Zx48K5UGlwSEJpHJYgKCfYqJpQGg/qeSaR2o6bQ5xj3lP7lRahVHHHl5 ffzCTZwGeYpz1Kfd6MpF3gHoTEHmJRk8TIirEfO0LdgQKjIY21xZBsNnCT9FCL0r/Dv9+01Jgg57 czBjOf1jiKdlflqmsENbqlrfu1ujJuyqkpE08zS6G+rL4uXi9fpi3cvaaszP0zRkM2ddHdZHUVYh kHFBJRbXcUbauEwcPwgeaM2b7V9SIH1ooqjxOlPmM/NvsRp8dqjEvSNfhLEdZ9KOvQx9LJjAuhr4 /q+Mo2m5csRYTH4AFVEXutPkmMTQCiYztUp6As9/n3A2oXUe5iBLCUSESXgzZCPyzKP2BtWzgTis 2pODrltCfwW4Eh3BouOPdIhGOgal+oQkI2U5xdhVEf37CpJQ1vAnNZDLPXdJ2VJxxCkHOZmIkBHa 5Loci51UzMqIm29tIwQJrDRMA2u2oClmSfD5HAcywqid3U8vQYGrnl2MVmBeEAT4m1cM+xXdzCAZ oLiKBWFiEV/WRpCODAKMCB0X7/SilbR4o88JEQQv4mBKWD3vO8j332lcOAaxrJ87GGBDDP9A0GeN GM9PYVFa6F46fDxBGuKDYMbDEiEODu2lK7BHji0Z4ADRqzbKIVyy7kaNpBkWyyQ1zkJUtvBXCfdQ PqJRegsPu/X9dUasDnKzSk3KMD4MRD13SckE0SLtY5JpsEjW8KIWhOariX46pIsCdCbRORuwpCh7 tpKZuJUNXYdVf58u7toD0jAvrRuIhsJC01SxG2C56GXWU2A1BswqZGUSEhBkgm98n9/37rWyvMiD 4VDki1Afb4Shdm4VyT39lCSpcwzzMEewgogbUFCDJZC2eqbiCF8uRW6Q6YI679sR3t1JaoUDaydi +iRqWzyWcsuMl2MTBBaQ1a2llAoE6ZzOOdr6LHAgzus4vBlirrCkshm7gHfI2fWupF87MTYsyGFI zNquCngPVgMDbOhBEPdL16BLCVRF3M6O+QhAU+KEGW5ihKOm262EEI5QCyuaKed+G5/frIaIhilA ULu5PbFHysBhTVH3Og3QKBWY14hpyFvvN3VaWnLOsYjkDFuyQQHV3hviSzPx23iZeMGwOR3G76au puBr6Yjj8ZpRBTFvhBruaR12LHmOvHaj7S9JbL/zFteXFVOBlIttzq9jUyolqYOb2RDPx1uoriWi FdYcEnC9WA3m8PKtLBZiWaORWZB9/4n3BOfIBhCE0N+TReE3pRM6457qBw2rc4gPCgbrAYJpWEdO 4XwuK5LPrENG1+BmGLu4eXnDvOiMTUuEX6CwIEpXiaCK1C/QXq9YuRMh13Qvqfnqf0zKcgz7XFYj WdVoBd4izmBffRekkWuKTwSv3AYB62IvKdrrRsOgwx0C9+09pAvXJiwO2spJFkqKpUxJCjNMwcAy Rl55BAVSttBGFlRKFNSBCIQSmVTIDb4DWaWEClEZRil7kBtZszWTQMGV8R8Btoh49FKIrmbIQ9NU 0e9uGGpLgWZ2sg21LWLe6lhDD3b2VjkeMhN8WBz7RaAEpBIQkAlBEmAPBqb+dAeodANY+F6A7oyi y6EKXC55ab6v4xEOESGJ7vRIFDnr4DCqq/0kBt+L4pZKwZ7g8GpXRBusGaDXsEIfNv0pj0R0X1k1 Oqpo24sWp5o+LzZoVNTMglXeFgVVlpght3OwY2gvyk46I+4R2STcedEyFGVMCMAvM0mEUVGJWfCc 7qNuUBUeRJdL4w3dEE6r2k3AjqPPxhxOK6wkKssGqNyYNjQNIJl3vd2MVBs7dodOo3lrwJPv90k/ ZL+uxQo1Pxmg/ngyLIbR5sEUk0MxMTGe2BhGo5REDVgFC4LckF79m6KnPW2w3KCYMjOiokrapjRi CKWXuFdhVrKqDBXF7SgcFpsENKuIkNlA6kk0zJFZIZdd72sCIdhxbQUMg2aZJ1IyBEUkHrgmYbZH 1uwfstA8HgYCLADEaYghiwXeyRV9EFLq+RKsGBgtN9BCKQpOFkcFKuwKFsqlBGFcri6rMWovEIhD aJYlkhqjFTuhQ0TEVZCGKS9pfqBhuFQKErJfVei9kt6wwREVC4KiYmcDuS45KthxYayEfnogokgP 5hh1jIJgRlITDPvuLNT6kXKQ2UdwUVG9ttFFaoBYixIKzCwTCQEJiHEuseHywPZEfrf4pDeuFx6G rxN+2HAiBXh22PFwH2IJijUtai40uwP0LEQiy3JHy5B6g7rJBEo3s3meEJND4lEELWkMGMYlgFF6 A+gP/ZMWLOsHyXqstA0wZvW+5I/M+HaGyQsdpOp7OEWUQSmNUcakQ6/umwuPzBfreVgMt1F52t9l jmGQQ0KVyPYqv4JcrPgkaeeGPq/LlHjTIPXtD3tbfLc9JOiNla9+J3MR1o8LkbbdfpZG4udCExQL 1SlSeGClwd8IlqXg8OG2LyjCnhlKXcSJWgx7M1v34Y1RxYWCw1CMwkwuSk3FbvJQfQxAvZYvFywS InEk33bTUZzWpsEr2xbTW+UGaHNiixZdybJSK1KQRRzqhFRixFFURwqFNViZhewJDWmRaoc5WKse Y4iEYd4XSg3p5seNcY6jTDdcfXKLkNTCY0eJr0EI5FTIAobfp5EgH8fwb9c8hia07rqBUfRJzIiF kI4nV7OipJRHWw3Usw8tOQaKegkUhaTVMUZM9AyRFBhIbJA5OzD/UWMQ1A7bwoCzy60llrLGgVA2 QKAaRW8sCwRGMmCa4BhAtAUso/btv4tVy3b2+sUt3lku8eqKLICxkvagQl2T7sJBpiZSbxasAoHv uZC1RONsRyMY5tvzWaGyQMqTEzo6A77aumgqGCMGLEG8D2N8ehXY4h2kvpitx6C0AqaUhaRbP14I vPQUS24EZJWuN6wSyFk2zZYaaIb9kmssg8G2/S6J+tUqVVKjMNYZgZJUvd7DuUg22amS9jCRERQU xhJGFFJEyF2qGbUkyoIoQ84zNYR0WEFn6iDIRmoq4qA43LDXRJxGXUBKBDMPUaQoxDwyvMKu619N LnhhrUtCxnH5i8iVevl2JTQaX0Jxxm2g1b35a1E1sCzYjXQmFAjaxLRJaplmvMYMUJKqbSTfFBpr dmF4qH5AayoG62AqVOjR1GHBXBpVyxUBNd67ow4WaloaBRNo0wNcwwBl1aiwGqE2RnsMESDSDzXw kTlmla4mFV1ZhipFYLNEEL5NIPwM1KJLPn17PLj5uHEN55AXo8fmwRtOByFqth8O7ig5FAhQtB2x aVUKvpGdqgpItUl48dwGNR7GfuR2UY0LmdvQ5XnNIwzQ1UN0Bv5IoMFKKJWAgkSyQxQhykFGglbr rcArVF5RHh5yfOMsxe5H1CTYgNGfR5QiwwowInMYR+Ts3IPAPKJY+sjQ4CEYhE94X0kaMa8eNDa6 ZqovJBog/GLeJwBqKJ/xdyRThQkCpHEcAA== --Multipart=_Sun__11_Jan_2004_13_59_00_+0000__w4ZBaR2oW0h.mhe-- From amir.noam@intel.com Sun Jan 11 06:28:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 06:28:54 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BEST6H018024 for ; Sun, 11 Jan 2004 06:28:31 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i0BESBW6032438; Sun, 11 Jan 2004 14:28:11 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i0BERqXG015537; Sun, 11 Jan 2004 14:28:10 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011116281017230 ; Sun, 11 Jan 2004 16:28:10 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i0BES8hb002422; Sun, 11 Jan 2004 16:28:09 +0200 (IST) From: Amir Noam To: "Jeff Garzik" Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces Date: Sun, 11 Jan 2004 16:28:07 +0200 User-Agent: KMail/1.5.3 Cc: , References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401111628.07930.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2337 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 2438 Lines: 61 On Sunday 11 January 2004 03:34 am, Jeff Garzik wrote: > Amir Noam wrote: > > The following patch sets provide basic support for future bonding > > operations (specifically for dynamic configuration of bonding > > interfaces). > > > > This is done by adding two new bonding ioctls: one for deviceless > > commands (an ioctl hook) and one for device oriented commands. > > Like ethtool, the first u32 value in the data structure will > > indicate the exact sub-command to be executed. > > > > The sets are against the latest netdev-2.4 and > > net-drivers-2.5-exp trees. > > I don't disagree with the overall goal of these patches, but I > think we might need to pause a bit, and consider how best to > configure, add, and remove bonding interfaces, if we are coming up > with a new interface. > > > For configuration tasks that occur outside the scope of a single > bonding interface (i.e. a single struct net_device), you need a > separate entity from a socket ioctl. It's not ideal at all to > configure N objects using a special ioctl ... when opening one of > said objects :) That's not exactly what the new ioctls do. The new SIOCBONDING ioctl handles commands aimed for the bonding module (and not to any specific bonding interface). This is done via an ioctl hook that captures these commands at the socket level (before dev_ioctl()) and passes it to the bonding code. Such commands do not require opening a bonding interface at all, just a valid socket to send the ioctl. Also, such commands do not configure N other objects (like bonding interfaces) at all. They are used explicitly for "deviceless" commands, like dynamically adding and removing a bonding interface from the system. > I would suggest a simple character device (misc_register), and let > the userland application configure settings unrelated to a single > object. I was trying to follow the example of several other network modules (e.g. vlan, dlci, bridge) that use a socket level ioctl hook to handle such deviceless commands. Do you think that a char device is preferrable, given that other similar modules use a socket ioctl hook? > For a configuring state related to a _single_ bonding interface > (i.e. a single net_device), socket ioctls are OK. For such configuration commands (aimed at a specific bonding interface) I've added the SIOCBONDDEVICE ioctl, which is designed to be extendable to more commands in the future. -- Amir From amir.noam@intel.com Sun Jan 11 06:50:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 06:51:06 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BEon6H018934 for ; Sun, 11 Jan 2004 06:50:52 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i0BEoRW6002604; Sun, 11 Jan 2004 14:50:27 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i0BEoRX6017396; Sun, 11 Jan 2004 14:50:27 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011116502617806 ; Sun, 11 Jan 2004 16:50:26 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i0BEoOhb003012; Sun, 11 Jan 2004 16:50:25 +0200 (IST) From: Amir Noam To: "Per Hedeland" Subject: Re: [Bonding-devel] [PATCH] [bonding 2.4] Add balance-xor-ip bonding mode Date: Sun, 11 Jan 2004 16:50:24 +0200 User-Agent: KMail/1.5.3 Cc: , References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401111650.24305.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2338 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 1247 Lines: 30 On Thursday 08 January 2004 06:43 pm, Per Hedeland wrote: > Amir Noam wrote: > >I don't like this. The reason we give different tx function > > pointers to dev->hard_start_xmit in different bonding mode is to > > make the tx path as fast as possible. Otherwise we might as well > > use a single tx function that chooses its exact operation based > > on the bonding mode. > > > >It might be better to have some code duplication if it results in > >faster tx, but I'm not sure what's the optimal solution in this > > case. > > Well, I don't really have an opinion since I don't have a good idea > about the cost of a function call relative to "everything else" > that is happening here. I don't see a way to do "limited" > duplication without using function calls though, but I'm quite > happy to make it two entirely separate functions for MAC vs IP. > Please advise. A possible way to have "limited" duplication would be to have two seperate xmit functions, that call an inline function for the shared code. This might be good enough, performance-wise, while avoiding some code duplication. But, like I've said, I'm not sure wout the best solution is. I'd like to hear what Jay (and others) thinks about it. -- Amir From pollockd@webmail1.magma.ca Sun Jan 11 08:24:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 08:24:24 -0800 (PST) Received: from mx2.magma.ca (mx2.magma.ca [206.191.0.250]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BGO96H025306 for ; Sun, 11 Jan 2004 08:24:10 -0800 Received: from webmail1.magma.ca (webmail1.magma.ca [206.191.0.241]) by mx2.magma.ca (Magma Relay Server) with ESMTP id i0BGNhq6013078; Sun, 11 Jan 2004 11:23:43 -0500 Received: (from pollockd@localhost) by webmail1.magma.ca (Magma's Mail Server) id i0BGNg3O028990; Sun, 11 Jan 2004 11:23:42 -0500 (EST) Date: Sun, 11 Jan 2004 11:23:42 -0500 (EST) Message-Id: <200401111623.i0BGNg3O028990@webmail1.magma.ca> To: Francois Romieu , Jeff Garzik From: "Douglas Pollock" Subject: Re: Realtek 8169 Lock-ups Cc: netdev@oss.sgi.com, damouse@ntlworld.com, brad@mainstreetsoftworks.com, kinetik@orcon.net.nz X-Account: pollockd X-Sender-IP: 209.217.84.59 X-INFO: Folder - 0, Message - 0, MimeBody - 0 Mime-Version: 1.0 Content-Type: text/plain X-archive-position: 2339 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pollockd@magma.ca Precedence: bulk X-list: netdev Content-Length: 882 Lines: 23 On Jan 11, Francois Romieu wrote: > M. Pollock's problems look different: > - they do not depend on the driver used; I can confirm that I do not see kernel panics, and that the driver (for all intents and purposes) seems to work well for a period of time. > - they seem timing/smp related (mobile computer + p4 HT). I ran without SMP support in the kernel for about 1.5 days on my work network, and did not see any of the lock-ups described. However, this evidence is somewhat circumstantial, as we don't have a reproducible test case. It would be nice if someone could point me to a network stress testing tool (something that opens multiple simultaneous connections and keeps them at high load). I'm hoping that such a test might provide a reproducible test case. This way we could confirm or rule-out the SMP relationship. Thanks, Doug. From berk@upnet.ru Sun Jan 11 08:33:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 08:33:24 -0800 (PST) Received: from upnet.ru (upnet.ru [217.107.116.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BGWx6H025928 for ; Sun, 11 Jan 2004 08:33:00 -0800 Received: (qmail 23673 invoked from network); 11 Jan 2004 16:14:56 -0000 Received: from vikul-61-206-98.net-burg.net (HELO rage) (berk@[212.220.206.98]) (envelope-sender ) by upnet.ru (qmail-ldap-1.03) with SMTP for ; 11 Jan 2004 16:14:56 -0000 From: Stanislav Karchebny Organization: eXQuance To: netdev@oss.sgi.com Subject: forcedeth 0.20 eth0: received interrupt report Date: Sun, 11 Jan 2004 21:33:54 +0500 User-Agent: KMail/1.5.94 Cc: Carl-Daniel Hailfinger MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_9rXAACFcySNAWxL"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200401112134.05375.berk@upnet.ru> X-archive-position: 2340 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: berk@upnet.ru Precedence: bulk X-list: netdev Content-Length: 1024 Lines: 40 --Boundary-02=_9rXAACFcySNAWxL Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline "eth0: received irq with unknown events 0x21. Please report" This happens when i enable software CPU cooling on nForce2 chipset using=20 =46Vcool - this causes all nforce-net connections to fail miserably and the= se=20 events are generated in dmesg log. The very moment i disable softcooling using fvcool -d the network resumes=20 normal operations. Linux Kernel 2.6.0 final forcedeth 0.20 ASUS A7N8X Deluxe mobo =46eel free to contact me if you need any additional information/debug=20 runs/testing help. =2D-=20 keep in touch. berkus. --Boundary-02=_9rXAACFcySNAWxL Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQBAAXr98v4MNv5cuDkRAm+pAJ98Sw3R3DXyJYku07RSLx6tZZGqeACeOGRM zVfq+J1t1yyzzxMBhCQ+bEc= =Jrxj -----END PGP SIGNATURE----- --Boundary-02=_9rXAACFcySNAWxL-- From jgarzik@pobox.com Sun Jan 11 11:39:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 11:40:05 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BJdp6H010811 for ; Sun, 11 Jan 2004 11:39:52 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:34853 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AflR3-0008B2-3Q; Sun, 11 Jan 2004 19:39:45 +0000 Message-ID: <4001A667.2020904@pobox.com> Date: Sun, 11 Jan 2004 14:39:19 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Amir Noam CC: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, hadi@cyberus.ca, Ben Greear Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces References: <200401111628.07930.amir.noam@intel.com> In-Reply-To: <200401111628.07930.amir.noam@intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2341 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 Content-Length: 1947 Lines: 46 Amir Noam wrote: > The new SIOCBONDING ioctl handles commands aimed for the bonding > module (and not to any specific bonding interface). This is done via > an ioctl hook that captures these commands at the socket level > (before dev_ioctl()) and passes it to the bonding code. Such commands > do not require opening a bonding interface at all, just a valid > socket to send the ioctl. Right. And this last requirement is spurious. The operation is essentially "open a socket unrelated to X, to perform actions on X". bonding (and it sounds like VLAN too) needs a specific, well-known control point, for controlling module-level data such as the creation and deletion of interfaces. One such well-known control point would be a /dev node. Jamal's suggestion is also an excellent one: let userspace use netlink to communicate with a well known "address" inside the kernel, which would work as the central (and thus bonding-module-wide) bonding control interface. > I was trying to follow the example of several other network modules > (e.g. vlan, dlci, bridge) that use a socket level ioctl hook to > handle such deviceless commands. > > Do you think that a char device is preferrable, given that other > similar modules use a socket ioctl hook? If vlan/dlci/bridge has similar requirements to described above ("open socket unrelated to X, to perform actions on X") then they need to be fixed up too. Opening a random socket to use an ioctl(2) to produce some magic behavior is just ugly, and we need to avoid that. Maybe bgreear would be open to updating VLAN's interface to netlink at the same time, for example? That would allow us (us==netdev) to understand all angles and implications of a good interface design. VLAN AFAICS has a similar requirement: need an interface _unrelated_ to specific VLAN interfaces, to control VLAN interfaces. And netlink certainly works as a control protocol :) Jeff From greearb@candelatech.com Sun Jan 11 13:34:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 13:34:49 -0800 (PST) Received: from ns1.wanfear.com (ns1.wanfear.com [207.212.57.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BLYZ6H020008 for ; Sun, 11 Jan 2004 13:34:36 -0800 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by ns1.wanfear.com (8.12.10/8.12.8) with ESMTP id i0BLYG9v021064; Sun, 11 Jan 2004 13:34:16 -0800 Message-ID: <4001C158.6040103@candelatech.com> Date: Sun, 11 Jan 2004 13:34:16 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Amir Noam , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> In-Reply-To: <4001A667.2020904@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2342 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 Content-Length: 2399 Lines: 61 Jeff Garzik wrote: > Amir Noam wrote: > >> The new SIOCBONDING ioctl handles commands aimed for the bonding >> module (and not to any specific bonding interface). This is done via >> an ioctl hook that captures these commands at the socket level (before >> dev_ioctl()) and passes it to the bonding code. Such commands do not >> require opening a bonding interface at all, just a valid socket to >> send the ioctl. > > > Right. And this last requirement is spurious. The operation is > essentially "open a socket unrelated to X, to perform actions on X". > > bonding (and it sounds like VLAN too) needs a specific, well-known > control point, for controlling module-level data such as the creation > and deletion of interfaces. > > One such well-known control point would be a /dev node. Jamal's > suggestion is also an excellent one: let userspace use netlink to > communicate with a well known "address" inside the kernel, which would > work as the central (and thus bonding-module-wide) bonding control > interface. > > >> I was trying to follow the example of several other network modules >> (e.g. vlan, dlci, bridge) that use a socket level ioctl hook to handle >> such deviceless commands. >> >> Do you think that a char device is preferrable, given that other >> similar modules use a socket ioctl hook? > > > If vlan/dlci/bridge has similar requirements to described above ("open > socket unrelated to X, to perform actions on X") then they need to be > fixed up too. > > Opening a random socket to use an ioctl(2) to produce some magic > behavior is just ugly, and we need to avoid that. Maybe bgreear would > be open to updating VLAN's interface to netlink at the same time, for Actually, I am not a fan of netlink for normal configuration, and would prefer to keep the VLAN control through IOCTL calls. This is mainly because I have not had an easy time of figuring out a simple way to use netlink, while ioctls are very easy to use. If someone wants to update vlan and vconfig to use netlink, then maybe we could add that API as well, but definately we should not remove the IOCTL calls untill at least 2.7. I would also be open to moving the VLAN ioctls over into the ethtool ioctl space, but that just exchanges one magic ioctl for another... Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From per@hedeland.org Sun Jan 11 13:45:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 13:45:44 -0800 (PST) Received: from pluto.hedeland.org (as1-2-8.mal.s.bonet.se [194.236.4.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BLjT6H021419 for ; Sun, 11 Jan 2004 13:45:30 -0800 Received: from pluto.hedeland.org (localhost [127.0.0.1]) by pluto.hedeland.org (8.12.10/8.12.10) with ESMTP id i0BLjGUG095608 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 11 Jan 2004 22:45:16 +0100 (CET) Received: (from per@localhost) by pluto.hedeland.org (8.12.10/8.12.10/Submit) id i0BLjGWJ095607; Sun, 11 Jan 2004 22:45:16 +0100 (CET) Date: Sun, 11 Jan 2004 22:45:16 +0100 (CET) From: Per Hedeland Message-Id: <200401112145.i0BLjGWJ095607@pluto.hedeland.org> To: amir.noam@intel.com Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] [PATCH] [bonding 2.4] Add balance-xor-ip bonding mode In-Reply-To: <200401111650.24305.amir.noam@intel.com> X-archive-position: 2343 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: per@hedeland.org Precedence: bulk X-list: netdev Content-Length: 2920 Lines: 59 Amir Noam wrote: > >A possible way to have "limited" duplication would be to have two >seperate xmit functions, that call an inline function for the shared >code. This might be good enough, performance-wise, while avoiding >some code duplication. Yes, I actually thought of that (after the previous post:-) - it would at least avoid some *source* code duplication. And the reasonable thing to break out into such a function would be the logic to find the slave to xmit on given slave_no (perhaps also the actual xmit), I guess. However when looking at this I realized that the xor mode has a pretty serious bug/flaw in the fault-tolerance department: The modulus is done with the total number of slaves, and slaves that are down are only skipped in that find-slave logic. I.e. if you (e.g.) have a bond with 3 links where link 1 is down, link 2 will get 2/3 of the traffic and link 3 get 1/3 - not good I think. Since fixing this would likely change the interface to the above function, I guess it would be nice to do it at the same time as (or before) the balance-xor-ip addition. Assuming I'm not the only one that thinks it needs fixing, that is.:-) The superficially obvious fix is to do the modulus with only the number of slaves that are up, but I'm not sure about the best actual implementation. That number isn't currently maintained, and traversing the list of slaves just to find it for every packet doesn't make sense of course. It seems straightforward to add another field to the bonding struct for it, and maintain that in the monitoring functions, though. But in addition to that, the actual slave selection logic would have to always check the link state of each slave until it has found the slave_no'th one that is up (though one could optimize for the case of all slaves being up) - whereas currently it only starts checking at the slave_no'th one, and if all slaves are up there is only one check. I'm not sure if this is acceptable? The only alternative I see is to also maintain a list of the slaves that are up, but then we're perhaps getting too much complexity for these "simple" modes. Any comments, other alternatives? >But, like I've said, I'm not sure wout the best solution is. I'd like >to hear what Jay (and others) thinks about it. Well, Jay said he would be out of email access for three weeks - starting tomorrow and promising he would look over updated patches first, but maybe he didn't have the time - or, given that you objected:-), he (correctly) thought that a second update wouldn't arrive in time. I'm in no particular hurry to get this into the "official" source though, since I'll be using an older kernel that I've already applied the (original) patch to for a while anyway - it's just that it gets old pretty quickly to keep reworking the patches against moving (and not very easily accessible) targets... --Per Hedeland per@hedeland.org From c-d.hailfinger.kernel.2003@gmx.net Sun Jan 11 14:41:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 14:41:42 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BMfS6H026720 for ; Sun, 11 Jan 2004 14:41:28 -0800 Received: (qmail 2086 invoked by uid 65534); 11 Jan 2004 22:41:21 -0000 Received: from stud213094.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.213.94) by mail.gmx.net (mp021) with SMTP; 11 Jan 2004 23:41:21 +0100 X-Authenticated: #15936885 Message-ID: <4001D113.3030302@gmx.net> Date: Sun, 11 Jan 2004 23:41:23 +0100 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en MIME-Version: 1.0 To: madis CC: Madis Janson , netdev@oss.sgi.com Subject: Re: forcedeth unknown events 0x21 References: <3FE6678B.5070006@gmx.net> In-Reply-To: X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2344 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2003@gmx.net Precedence: bulk X-list: netdev Content-Length: 1064 Lines: 38 madis wrote: > On Mon, 22 Dec 2003, Carl-Daniel Hailfinger wrote: > >>Madis Janson wrote: >> >>>When trying forcedeth_2_6_patch_v19.txt, i got the following message >>>fastly repeating after ifup eth0: >>> >>>"eth0: received irq with unknown events 0x21. Please report" >>> >>>and it didn't work eighter (ifup just stalled). [...] >> >>Please try the attached patch on top of it and report back if it works. > > the unknown events message disappeared, > but the network did not start to work... Do you use any powermanagement software (athcool, lvcool, fvcool, coolon, athlon cooling patch, anything STPGNT related)? Does your BIOS list anything STPGNT related? > + if (events & (NVREG_IRQ_RX_ERR)) { > + dprintk(KERN_DEBUG "%s: received irq with events > 0x%x. > Probably RX fail.\n", > + dev->name, events); > here were '}' missing. Thanks for the hint. If you see anything powermanagement related enabled, please disable it and try again. Does that fix it? Carl-Daniel From hadi@cyberus.ca Sun Jan 11 14:51:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 14:51:30 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BMp66H027486 for ; Sun, 11 Jan 2004 14:51:06 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1AfoQ9-0001Rv-CS; Sun, 11 Jan 2004 17:51:01 -0500 Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces From: jamal Reply-To: hadi@cyberus.ca To: Jeff Garzik Cc: Ben Greear , Amir Noam , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <4001C72E.8030108@pobox.com> References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> <4001C72E.8030108@pobox.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1073861429.1119.312.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Jan 2004 17:50:29 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2345 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 Content-Length: 854 Lines: 20 On Sun, 2004-01-11 at 16:59, Jeff Garzik wrote: > ioctls are a pain for 32/64-bit emulation layers too. It seems much > easier to define a netlink protocol family of some sort and communicate > that way. > > I'll poke around and see what I can come up with. Theres a L2C netlink protocol (for Layer2 Config) which is already in place being reviewed by DaveM in whatever spurious time he has. Current user is MPLS but definete candidate for VLAN, and the move of bridging STP control to user space. It is true that netlink may not be intuitive to use for someone who hasnt spent time eyeballing it(mostly because of lack of programming docs really). We are going to try and improve things by making it easy to use from both kernel and user space POV and provide sample code which people can cutnpaste in the classical linux-way(tm). cheers, jamal From greearb@candelatech.com Sun Jan 11 14:51:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 14:51:42 -0800 (PST) Received: from ns1.wanfear.com (ns1.wanfear.com [207.212.57.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BMpT6H027500 for ; Sun, 11 Jan 2004 14:51:29 -0800 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by ns1.wanfear.com (8.12.10/8.12.8) with ESMTP id i0BMpN9v025245; Sun, 11 Jan 2004 14:51:23 -0800 Message-ID: <4001D36B.8070402@candelatech.com> Date: Sun, 11 Jan 2004 14:51:23 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Amir Noam , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> <4001C72E.8030108@pobox.com> In-Reply-To: <4001C72E.8030108@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2346 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 Content-Length: 1306 Lines: 38 Jeff Garzik wrote: > Ben Greear wrote: > >> I would also be open to moving the VLAN ioctls over into the >> ethtool ioctl space, but that just exchanges one magic ioctl for >> another... > > > > The key question is what is the best interface for userland to configure > in-kernel information -that is unrelated to a specific interface-. > ethtool ioctl space doesn't apply, because that's a per-interface API. Actually, VLANs map very well to a per-interface API, since VLANs are interfaces and reside on other interfaces. > Opening a socket and just ioctl'ing away isn't terribly scalable in the > long run, either. Consider all the applications that could legitimately > claim they need a SIOCxxx ioctl assignment, just for their little slice > of the networking world. Further, consider that all an ioctl is is a My assumption is that adding a new ethtool message (or vlan ioctl message to the existing VLAN ioctl call) does not cause new emulation problems. Is that true? > I'll poke around and see what I can come up with. I'm interested in seeing the result. I've never found a simple example of something using the netlink api, and if it can be done, then I'll probably convert. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jgarzik@pobox.com Sun Jan 11 14:58:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 14:58:52 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BMwc6H028530 for ; Sun, 11 Jan 2004 14:58:39 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:34898 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AfncO-0001L6-BC; Sun, 11 Jan 2004 21:59:36 +0000 Message-ID: <4001C72E.8030108@pobox.com> Date: Sun, 11 Jan 2004 16:59:10 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Greear CC: Amir Noam , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> In-Reply-To: <4001C158.6040103@candelatech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2347 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 Content-Length: 967 Lines: 27 Ben Greear wrote: > I would also be open to moving the VLAN ioctls over into the > ethtool ioctl space, but that just exchanges one magic ioctl for > another... The key question is what is the best interface for userland to configure in-kernel information -that is unrelated to a specific interface-. ethtool ioctl space doesn't apply, because that's a per-interface API. Opening a socket and just ioctl'ing away isn't terribly scalable in the long run, either. Consider all the applications that could legitimately claim they need a SIOCxxx ioctl assignment, just for their little slice of the networking world. Further, consider that all an ioctl is is a message sent to the kernel driver, perhaps sending and/or receiving some data. :) ioctls are a pain for 32/64-bit emulation layers too. It seems much easier to define a netlink protocol family of some sort and communicate that way. I'll poke around and see what I can come up with. Jeff From c-d.hailfinger.kernel.2003@gmx.net Sun Jan 11 15:04:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 15:04:34 -0800 (PST) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BN4K6H029152 for ; Sun, 11 Jan 2004 15:04:21 -0800 Received: (qmail 12120 invoked by uid 65534); 11 Jan 2004 23:04:15 -0000 Received: from stud213094.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.213.94) by mail.gmx.net (mp015) with SMTP; 12 Jan 2004 00:04:15 +0100 X-Authenticated: #15936885 Message-ID: <4001D671.6030008@gmx.net> Date: Mon, 12 Jan 2004 00:04:17 +0100 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en MIME-Version: 1.0 To: Stanislav Karchebny CC: netdev@oss.sgi.com Subject: Re: forcedeth 0.20 eth0: received interrupt report References: <200401112134.05375.berk@upnet.ru> In-Reply-To: <200401112134.05375.berk@upnet.ru> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2348 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2003@gmx.net Precedence: bulk X-list: netdev Content-Length: 1218 Lines: 34 Stanislav Karchebny wrote: > "eth0: received irq with unknown events 0x21. Please report" > > This happens when i enable software CPU cooling on nForce2 chipset using > FVcool - this causes all nforce-net connections to fail miserably and these > events are generated in dmesg log. > > The very moment i disable softcooling using fvcool -d the network resumes > normal operations. > > Linux Kernel 2.6.0 final > forcedeth 0.20 > ASUS A7N8X Deluxe mobo Great! You're the first one finding out why this unknown event 0x01 happens. (0x20 is timer event) Since another user saw the same message but wasn't able to get the network running at all, I was stuck. Enabling normal receive doesn't help to get rid of the error. I know that nvnet is proprietary software and also not that stable according to user reports, but could you perhaps try nvnet instead of forcedeth? If nvnet still works when you enable softcooling, I can try to add a workaround to forcedeth so that it works, too. If nvnet fails, I still can try a few tricks but I'd have to know more than the nvnet driver writers about the nforce chipset and they are inside nvidia and I don't even have any docs. Thanks for your coperation, Carl-Daniel From gnb@melbourne.sgi.com Sun Jan 11 16:12:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 16:13:05 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0C0Cp6H032249 for ; Sun, 11 Jan 2004 16:12:52 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i0C1Vnr3027284 for ; Sun, 11 Jan 2004 19:31:50 -0600 Received: from melbourne.sgi.com (speed.melbourne.sgi.com [134.14.55.174]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA25305; Mon, 12 Jan 2004 11:12:35 +1100 Message-ID: <4001E673.59994F40@melbourne.sgi.com> Date: Mon, 12 Jan 2004 11:12:35 +1100 From: Greg Banks Organization: SGI Australian Software Group X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-6mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Garzik CC: Robert Olsson , "David S. Miller" , Linux Network Development list Subject: Re: [PATCH] make tg3 NAPI support configurable References: <3FE2F3A7.2A109F28@melbourne.sgi.com> <16354.64258.364153.488309@robur.slu.se> <4000ABBA.50601@pobox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2349 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gnb@melbourne.sgi.com Precedence: bulk X-list: netdev Content-Length: 547 Lines: 16 Jeff Garzik wrote: > > Robert Olsson wrote: > > You can use coalescing with NAPI as well, e1000 and other drivers > > are doing this. This will give you same interrupt rates as non- > > NAPI at low load and "polling" without any interrupts at high load. > > Yes, this is something I've been meaning to add to tg3 for months now. I'd be very happy to test patches on an Altix, where this issue is a significant networking scaling limitation. Greg. -- Greg Banks, R&D Software Engineer, SGI Australian Software Group. I don't speak for SGI. From linux-netdev@gmane.org Sun Jan 11 16:13:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 16:14:05 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0C0Dn6H032338 for ; Sun, 11 Jan 2004 16:13:51 -0800 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AfpiF-0003w8-00 for ; Mon, 12 Jan 2004 01:13:47 +0100 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 1AfpiE-0003w0-00 for ; Mon, 12 Jan 2004 01:13:46 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AfpiE-0007J0-00 for ; Mon, 12 Jan 2004 01:13:46 +0100 From: Jason Lunz Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces Date: Mon, 12 Jan 2004 00:13:46 +0000 (UTC) Organization: PBR Streetgang Message-ID: References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> <4001C72E.8030108@pobox.com> X-Complaints-To: usenet@sea.gmane.org User-Agent: slrn/0.9.8.0 (Linux) X-archive-position: 2350 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lunz@falooley.org Precedence: bulk X-list: netdev Content-Length: 1041 Lines: 33 jgarzik@pobox.com said: > The key question is what is the best interface for userland to configure > in-kernel information -that is unrelated to a specific interface-. > ethtool ioctl space doesn't apply, because that's a per-interface API. ethtool is just as bad as brctl or any of the others. From (userland) ethtool.c: static int doit(void) { struct ifreq ifr; int fd; /* Setup our control structures. */ memset(&ifr, 0, sizeof(ifr)); strcpy(ifr.ifr_name, devname); /* Open control socket. */ fd = socket(AF_INET, SOCK_DGRAM, 0); if (fd < 0) { perror("Cannot get control socket"); return 70; } /* now do ioctl() on fd, having nothing to do with * AF_INET nor SOCK_DGRAM */ calling a spade a spade, and all that. I don't see how that's any better than brctl. The per-interface only comes into it when you copy a dev name into a struct ifreq, but that doesn't associate the fd with the interface in any way. You could go ahead and issue another ioctl on the same fd for a different interface. Jason From dlstevens@us.ibm.com Sun Jan 11 21:49:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 21:49:41 -0800 (PST) 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.9) with SMTP id i0C5nL6H017893 for ; Sun, 11 Jan 2004 21:49:28 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0C5nC19499022; Mon, 12 Jan 2004 00:49:12 -0500 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0C5nBuU169890; Sun, 11 Jan 2004 22:49:11 -0700 Importance: Normal Sensitivity: Subject: Re: MLD problems (again) [PATCH] To: Takashi Hibi Cc: netdev@oss.sgi.com, davem@redhat.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Sun, 11 Jan 2004 22:49:08 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/11/2004 22:49:11 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=07BBE48ADF8C98F98f9e8a93df938690918c07BBE48ADF8C98F9" X-archive-position: 2351 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 6084 Lines: 147 --0__=07BBE48ADF8C98F98f9e8a93df938690918c07BBE48ADF8C98F9 Content-type: multipart/alternative; Boundary="1__=07BBE48ADF8C98F98f9e8a93df938690918c07BBE48ADF8C98F9" --1__=07BBE48ADF8C98F98f9e8a93df938690918c07BBE48ADF8C98F9 Content-type: text/plain; charset=US-ASCII Takashi, I believe the patch below will fix the problem you had with MCAST_JOIN_SOURCE_GROUP not sending a report. There was a typo in the source filter switching that did two deletes, rather than an delete and an add. Dave, Although IGMPv3 didn't have any problems, this patch also re-arranges the order of the filter changes. I think it's cleaner to add the new one first and then delete the old one, rather than having a small window with no filter set. So, this is a bug fix for MLD and a code clean-up for IGMPv3. This bug and patch should also apply to the 2.4 line. +-DLS [included in-line for viewing and as an attachment for unmangled whitespace] --- linux-2.6.1/net/ipv6/mcast.c 2004-01-08 22:59:56.000000000 -0800 +++ linux-2.6.1F1/net/ipv6/mcast.c 2004-01-11 21:06:05.000000000 -0800 @@ -372,9 +372,9 @@ goto done; } else if (pmc->sfmode != omode) { /* allow mode switches for empty-set filters */ + ip6_mc_add_src(idev, group, omode, 0, 0, 0); ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); pmc->sfmode = omode; - ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); } psl = pmc->sflist; --- linux-2.6.1/net/ipv4/igmp.c 2004-01-08 23:00:12.000000000 -0800 +++ linux-2.6.1F1/net/ipv4/igmp.c 2004-01-11 21:27:41.000000000 -0800 @@ -1749,11 +1749,10 @@ goto done; } else if (pmc->sfmode != omode) { /* allow mode switches for empty-set filters */ + ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, omode, 0, 0, 0); ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, 0, 0); pmc->sfmode = omode; - ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, - 0, 0); } psl = pmc->sflist; (See attached file: 2.6.1MLD.patch) --1__=07BBE48ADF8C98F98f9e8a93df938690918c07BBE48ADF8C98F9 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Takashi,
I believe the patch below will fix the problem you
had with MCAST_JOIN_SOURCE_GROUP not sending a
report. There was a typo in the source filter switching that did
two deletes, rather than an delete and an add.

Dave,
Although IGMPv3 didn't have any problems, this patch
also re-arranges the order of the filter changes. I think it's cleaner
to add the new one first and then delete the old one, rather than
having a small window with no filter set. So, this is a bug fix for MLD
and a code clean-up for IGMPv3.
This bug and patch should also apply to the 2.4 line.

+-DLS

[included in-line for viewing and as an attachment for unmangled
whitespace]

--- linux-2.6.1/net/ipv6/mcast.c 2004-01-08 22:59:56.000000000 -0800
+++ linux-2.6.1F1/net/ipv6/mcast.c 2004-01-11 21:06:05.000000000 -0800
@@ -372,9 +372,9 @@
goto done;
} else if (pmc->sfmode != omode) {
/* allow mode switches for empty-set filters */
+ ip6_mc_add_src(idev, group, omode, 0, 0, 0);
ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0);
pmc->sfmode = omode;
- ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0);
}

psl = pmc->sflist;
--- linux-2.6.1/net/ipv4/igmp.c 2004-01-08 23:00:12.000000000 -0800
+++ linux-2.6.1F1/net/ipv4/igmp.c 2004-01-11 21:27:41.000000000 -0800
@@ -1749,11 +1749,10 @@
goto done;
} else if (pmc->sfmode != omode) {
/* allow mode switches for empty-set filters */
+ ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, omode, 0, 0, 0);
ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0,
0, 0);
pmc->sfmode = omode;
- ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0,
- 0, 0);
}

psl = pmc->sflist;

(See attached file: 2.6.1MLD.patch)
--1__=07BBE48ADF8C98F98f9e8a93df938690918c07BBE48ADF8C98F9-- --0__=07BBE48ADF8C98F98f9e8a93df938690918c07BBE48ADF8C98F9 Content-type: application/octet-stream; name="2.6.1MLD.patch" Content-Disposition: attachment; filename="2.6.1MLD.patch" Content-ID: <10__=07BBE48ADF8C98F98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 LS0tIGxpbnV4LTIuNi4xL25ldC9pcHY2L21jYXN0LmMJMjAwNC0wMS0wOCAyMjo1OTo1Ni4wMDAw MDAwMDAgLTA4MDAKKysrIGxpbnV4LTIuNi4xRjEvbmV0L2lwdjYvbWNhc3QuYwkyMDA0LTAxLTEx IDIxOjA2OjA1LjAwMDAwMDAwMCAtMDgwMApAQCAtMzcyLDkgKzM3Miw5IEBACiAJCQlnb3RvIGRv bmU7CiAJfSBlbHNlIGlmIChwbWMtPnNmbW9kZSAhPSBvbW9kZSkgewogCQkvKiBhbGxvdyBtb2Rl IHN3aXRjaGVzIGZvciBlbXB0eS1zZXQgZmlsdGVycyAqLworCQlpcDZfbWNfYWRkX3NyYyhpZGV2 LCBncm91cCwgb21vZGUsIDAsIDAsIDApOwogCQlpcDZfbWNfZGVsX3NyYyhpZGV2LCBncm91cCwg cG1jLT5zZm1vZGUsIDAsIDAsIDApOwogCQlwbWMtPnNmbW9kZSA9IG9tb2RlOwotCQlpcDZfbWNf ZGVsX3NyYyhpZGV2LCBncm91cCwgcG1jLT5zZm1vZGUsIDAsIDAsIDApOwogCX0KIAogCXBzbCA9 IHBtYy0+c2ZsaXN0OwotLS0gbGludXgtMi42LjEvbmV0L2lwdjQvaWdtcC5jCTIwMDQtMDEtMDgg MjM6MDA6MTIuMDAwMDAwMDAwIC0wODAwCisrKyBsaW51eC0yLjYuMUYxL25ldC9pcHY0L2lnbXAu YwkyMDA0LTAxLTExIDIxOjI3OjQxLjAwMDAwMDAwMCAtMDgwMApAQCAtMTc0OSwxMSArMTc0OSwx MCBAQAogCQkJZ290byBkb25lOwogCX0gZWxzZSBpZiAocG1jLT5zZm1vZGUgIT0gb21vZGUpIHsK IAkJLyogYWxsb3cgbW9kZSBzd2l0Y2hlcyBmb3IgZW1wdHktc2V0IGZpbHRlcnMgKi8KKwkJaXBf bWNfYWRkX3NyYyhpbl9kZXYsICZtcmVxcy0+aW1yX211bHRpYWRkciwgb21vZGUsIDAsIDAsIDAp OwogCQlpcF9tY19kZWxfc3JjKGluX2RldiwgJm1yZXFzLT5pbXJfbXVsdGlhZGRyLCBwbWMtPnNm bW9kZSwgMCwgCiAJCQkwLCAwKTsKIAkJcG1jLT5zZm1vZGUgPSBvbW9kZTsKLQkJaXBfbWNfYWRk X3NyYyhpbl9kZXYsICZtcmVxcy0+aW1yX211bHRpYWRkciwgcG1jLT5zZm1vZGUsIDAsIAotCQkJ MCwgMCk7CiAJfQogCiAJcHNsID0gcG1jLT5zZmxpc3Q7Cg== --0__=07BBE48ADF8C98F98f9e8a93df938690918c07BBE48ADF8C98F9-- From A.Verweij2@ewi.tudelft.nl Mon Jan 12 03:01:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 03:01:31 -0800 (PST) Received: from mailhst2.its.tudelft.nl (mailhst2.its.tudelft.nl [130.161.34.250]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CB1G6H003481 for ; Mon, 12 Jan 2004 03:01:17 -0800 Received: from elektron.its.tudelft.nl (elektron.its.tudelft.nl [130.161.33.15]) by mailhst2.its.tudelft.nl (8.11.6p2/8.11.6) with ESMTP id i0CB13l26574; Mon, 12 Jan 2004 12:01:04 +0100 (MET) Received: from localhost (verwei90@localhost) by elektron.its.tudelft.nl (8.9.3 (PHNE_26305)/8.9.3) with ESMTP id MAA04496; Mon, 12 Jan 2004 12:01:03 +0100 (MET) Date: Mon, 12 Jan 2004 12:01:02 +0100 (MET) From: Arjen Verweij Reply-To: a.verweij@student.tudelft.nl To: netdev@oss.sgi.com cc: c-d.hailfinger.kernel.2003@gmx.net Subject: [Forcedeth] Wake-on-LAN support? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2352 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: A.Verweij2@ewi.tudelft.nl Precedence: bulk X-list: netdev Content-Length: 602 Lines: 22 L.S., First, many thanks for your efforts. The driver works beautifully here, with 2.4.23 and 2.6.0-test11 alike. I was wondering if it is possible to add Wake-on-LAN support to the driver. NVidia claims their binary driver supports WOL, but it doesn't work one bit. It is possible to look into this? I have filed a bugtracker with the ACPI people, but they are somewhat understandably preoccupied with fixing laptop woes. URL: http://bugzilla.kernel.org/show_bug.cgi?id=1636 I am able to enable WOL at shutdown with pci-config from scyld.com, but this is obviously an ugly fix. Regards, Arjen From hibi665@oki.com Mon Jan 12 03:03:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 03:03:17 -0800 (PST) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CB336H003714 for ; Mon, 12 Jan 2004 03:03:04 -0800 Received: from aoi.okilab.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id UAA25234 for ; Mon, 12 Jan 2004 20:03:02 +0900 Received: (qmail 8224 invoked from network); 12 Jan 2004 20:03:01 +0900 Received: from dhcp23233.okilab.oki.co.jp (HELO kiso) (172.24.23.233) by aoi.okilab.oki.co.jp with SMTP; 12 Jan 2004 20:03:01 +0900 Message-Id: <20040112200448.6e8f22f7%hibi665@oki.com> MIME-Version: 1.0 Date: Mon, 12 Jan 2004 20:04:48 +0900 X-Mailer: Denshin 8 Go V32.1.4.3 X-My-Real-Login-Name: thibi; aoi From: Takashi Hibi To: David Stevens Cc: netdev@oss.sgi.com, davem@redhat.com In-Reply-To: (Your message of "Sun, 11 Jan 2004 22:49:08 -0700") References: Subject: Re: MLD problems (again) [PATCH] X-archive-position: 2353 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hibi665@oki.com Precedence: bulk X-list: netdev Content-Length: 2192 Lines: 65 David, Thank you for the patch. But at least it doesn't solve the problem for 2.4 line kernel. I will also test with 2.6.1 later. Regards, Takashi Hibi > > > > > Takashi, > I believe the patch below will fix the problem you > had with MCAST_JOIN_SOURCE_GROUP not sending a > report. There was a typo in the source filter switching that did > two deletes, rather than an delete and an add. > > Dave, > Although IGMPv3 didn't have any problems, this patch > also re-arranges the order of the filter changes. I think it's cleaner > to add the new one first and then delete the old one, rather than > having a small window with no filter set. So, this is a bug fix for MLD > and a code clean-up for IGMPv3. > This bug and patch should also apply to the 2.4 line. > > +-DLS > > [included in-line for viewing and as an attachment for unmangled > whitespace] > > --- linux-2.6.1/net/ipv6/mcast.c 2004-01-08 22:59:56.000000000 -0800 > +++ linux-2.6.1F1/net/ipv6/mcast.c 2004-01-11 21:06:05.000000000 -0800 > @@ -372,9 +372,9 @@ > goto done; > } else if (pmc->sfmode != omode) { > /* allow mode switches for empty-set filters */ > + ip6_mc_add_src(idev, group, omode, 0, 0, 0); > ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); > pmc->sfmode = omode; > - ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); > } > > psl = pmc->sflist; > --- linux-2.6.1/net/ipv4/igmp.c 2004-01-08 23:00:12.000000000 -0800 > +++ linux-2.6.1F1/net/ipv4/igmp.c 2004-01-11 21:27:41.000000000 -0800 > @@ -1749,11 +1749,10 @@ > goto done; > } else if (pmc->sfmode != omode) { > /* allow mode switches for empty-set filters */ > + ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, omode, 0, 0, 0); > ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, > 0, 0); > pmc->sfmode = omode; > - ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, > - 0, 0); > } > > psl = pmc->sflist; > > (See attached file: 2.6.1MLD.patch) From ak@suse.de Mon Jan 12 05:14:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 05:14:39 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CDEE6H026539 for ; Mon, 12 Jan 2004 05:14:15 -0800 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 44AA219D0760; Mon, 12 Jan 2004 13:38:25 +0100 (CET) Date: Mon, 12 Jan 2004 13:38:16 +0100 From: Andi Kleen To: Jeff Garzik Cc: greearb@candelatech.com, amir.noam@intel.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces Message-Id: <20040112133816.57993f44.ak@suse.de> In-Reply-To: <4001C72E.8030108@pobox.com> References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> <4001C72E.8030108@pobox.com> X-Mailer: Sylpheed version 0.9.7 (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: 2354 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 Content-Length: 566 Lines: 15 On Sun, 11 Jan 2004 16:59:10 -0500 Jeff Garzik wrote: > ioctls are a pain for 32/64-bit emulation layers too. It seems much > easier to define a netlink protocol family of some sort and communicate > that way. Actually that's not true. netlink is far worse for emulation layers when you break the protocol. e.g. the current ipsec/pf_key protocol is not compatible on x86-64 and it is near impossible to fix it without major surgery. With ioctls it would be far easier to fixbecause the infrastructure for emulation is already there. -Andi From hadi@cyberus.ca Mon Jan 12 05:51:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 05:51:52 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CDpd6H030473 for ; Mon, 12 Jan 2004 05:51:39 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Ag2Te-0007Z5-0e; Mon, 12 Jan 2004 08:51:34 -0500 Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces From: jamal Reply-To: hadi@cyberus.ca To: Andi Kleen Cc: Jeff Garzik , greearb@candelatech.com, amir.noam@intel.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <20040112133816.57993f44.ak@suse.de> References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> <4001C72E.8030108@pobox.com> <20040112133816.57993f44.ak@suse.de> Content-Type: text/plain Organization: jamalopolis Message-Id: <1073915461.1118.342.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Jan 2004 08:51:02 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2355 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 Content-Length: 877 Lines: 28 Andi, Can you point to specifics that break 64 bit emulation so we can avoid them? I have to admit the pf_key interaction is relatively unorthrodox but looked fine. What are the things you will perform surgery on? cheers, jamal On Mon, 2004-01-12 at 07:38, Andi Kleen wrote: > On Sun, 11 Jan 2004 16:59:10 -0500 > Jeff Garzik wrote: > > > > ioctls are a pain for 32/64-bit emulation layers too. It seems much > > easier to define a netlink protocol family of some sort and communicate > > that way. > > Actually that's not true. netlink is far worse for emulation layers when you > break the protocol. e.g. the current ipsec/pf_key protocol is not compatible > on x86-64 and it is near impossible to fix it without major surgery. > With ioctls it would be far easier to fixbecause the infrastructure for emulation > is already there. > > -Andi > From ak@suse.de Mon Jan 12 07:06:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 07:06:48 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CF6T6H000515 for ; Mon, 12 Jan 2004 07:06:30 -0800 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 3BD6F19D0D07; Mon, 12 Jan 2004 16:04:51 +0100 (CET) Date: Mon, 12 Jan 2004 16:04:46 +0100 From: Andi Kleen To: hadi@cyberus.ca Cc: jgarzik@pobox.com, greearb@candelatech.com, amir.noam@intel.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces Message-Id: <20040112160446.691e187e.ak@suse.de> In-Reply-To: <1073915461.1118.342.camel@jzny.localdomain> References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> <4001C72E.8030108@pobox.com> <20040112133816.57993f44.ak@suse.de> <1073915461.1118.342.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.7 (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: 2356 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 Content-Length: 1267 Lines: 38 On 12 Jan 2004 08:51:02 -0500 jamal wrote: > Andi, > Can you point to specifics that break 64 bit emulation so we can avoid > them? > I have to admit the pf_key interaction is relatively unorthrodox but > looked fine. Ok, here are the full rules: Standards: long/void * are disallowed use [su]{16,32,64} instead Non obvious problems specific to IA64 and x86-64 (they don't happen on sparc64/ppc64, that is why they were often not catched earlier): When you use [su]64: make sure the data element is explicitely padded to be on a 8 byte boundary in the structure. The reason is that alignof(u64) on i386 is 4 but 8 on ia64/x86-64 and the structure layout could change. also when you use 64bit types make sure the complete structure is padded to 8 bytes. The x86-64 ABI pads any data structure to the alignof() of its biggest member to get good alignment for arrays. This is what broke PF_KEY - it is missing this padding and the structure layout ends up differently with nested structures. > What are the things you will perform surgery on? I'm not sure I will because it is too ugly. Or at least I haven't found a nice elegant way for it yet. Currently you just cannot use ipsec from 32bit executables, you have to use 64bit. -Andi From olof@austin.ibm.com Mon Jan 12 08:42:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 08:43:00 -0800 (PST) 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.9) with SMTP id i0CGgk6H006908 for ; Mon, 12 Jan 2004 08:42:47 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0CGgd19485904; Mon, 12 Jan 2004 11:42:40 -0500 Received: from austin.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0CGgbqc154550; Mon, 12 Jan 2004 09:42:39 -0700 Received: from forte.austin.ibm.com (forte.austin.ibm.com [9.53.85.27]) by austin.ibm.com (8.12.10/8.12.10) with ESMTP id i0CGga8t037246; Mon, 12 Jan 2004 10:42:36 -0600 Received: from localhost (olof@localhost) by forte.austin.ibm.com (AIX4.3/8.9.3/8.9.3-client1.01) with ESMTP id KAA57698; Mon, 12 Jan 2004 10:42:36 -0600 Date: Mon, 12 Jan 2004 10:42:36 -0600 (CST) From: olof@austin.ibm.com To: netdev@oss.sgi.com cc: cramerj@intel.com, Subject: [2.4] e1000 leaking pci mappings on rx errors? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2357 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olof@austin.ibm.com Precedence: bulk X-list: netdev Content-Length: 1405 Lines: 35 We have a machine here (running a RHEL 2.4.21-based kernel), that started showing leakage of PCI mappings when the driver was upgraded from 5.1.11 to 5.2.20. The system is a large-config ppc64 machine with 8 interfaces, each running at or near full load. NAPI is enabled, frame size is 1500. We're seeing RX errors on eth0, which is the only interface that is leaking TCE entries (pci mappings). The system is also running at full cpu load, with each interface having it's irq bound to an individual CPU. It's always the interface being bound to cpu0 that's showing errors (could possibly be because of rx ring overruns?). With the previous version (5.1.11), we were still seeing the RX errors, but no TCE leaks. As far as I can tell, the driver is leaking less than one mapping per error, since there are more RX errors than total allocated TCE entries for the interface. Number of errors after a run is in the range of 15-20k, while number of used entries are in the range of 3-4k. Has anyone else seen anything like this? I noticed there's a slightly newer e1000 driver available, but I saw no changes that seemed relevant. -Olof Olof Johansson Office: 4F005/905 Linux on Power Development IBM Systems Group Email: olof@austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM From jgarzik@pobox.com Mon Jan 12 09:01:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 09:01:34 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CH1K6H007734 for ; Mon, 12 Jan 2004 09:01:21 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:34259 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AfUVW-0005UA-FS; Sun, 11 Jan 2004 01:35:14 +0000 Message-ID: <4000A838.5040808@pobox.com> Date: Sat, 10 Jan 2004 20:34:48 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Amir Noam CC: Jay Vosburgh , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces References: <200401081819.54484.amir.noam@intel.com> In-Reply-To: <200401081819.54484.amir.noam@intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2358 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 Content-Length: 1262 Lines: 32 Amir Noam wrote: > The following patch sets provide basic support for future bonding > operations (specifically for dynamic configuration of bonding > interfaces). > > This is done by adding two new bonding ioctls: one for deviceless > commands (an ioctl hook) and one for device oriented commands. Like > ethtool, the first u32 value in the data structure will indicate the > exact sub-command to be executed. > > The sets are against the latest netdev-2.4 and net-drivers-2.5-exp > trees. I don't disagree with the overall goal of these patches, but I think we might need to pause a bit, and consider how best to configure, add, and remove bonding interfaces, if we are coming up with a new interface. For configuration tasks that occur outside the scope of a single bonding interface (i.e. a single struct net_device), you need a separate entity from a socket ioctl. It's not ideal at all to configure N objects using a special ioctl ... when opening one of said objects :) I would suggest a simple character device (misc_register), and let the userland application configure settings unrelated to a single object. For a configuring state related to a _single_ bonding interface (i.e. a single net_device), socket ioctls are OK. Jeff From greearb@candelatech.com Mon Jan 12 09:24:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 09:24:14 -0800 (PST) Received: from ns1.wanfear.com (ns1.wanfear.com [207.212.57.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CHO16H008681 for ; Mon, 12 Jan 2004 09:24:01 -0800 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by ns1.wanfear.com (8.12.10/8.12.8) with ESMTP id i0CHNp9v029225; Mon, 12 Jan 2004 09:23:51 -0800 Message-ID: <4002D826.3080409@candelatech.com> Date: Mon, 12 Jan 2004 09:23:50 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Amir Noam , Jay Vosburgh , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces References: <200401081819.54484.amir.noam@intel.com> <4000A838.5040808@pobox.com> In-Reply-To: <4000A838.5040808@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2359 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 Content-Length: 2443 Lines: 60 Jeff Garzik wrote: > Amir Noam wrote: > >> The following patch sets provide basic support for future bonding >> operations (specifically for dynamic configuration of bonding >> interfaces). >> >> This is done by adding two new bonding ioctls: one for deviceless >> commands (an ioctl hook) and one for device oriented commands. Like >> ethtool, the first u32 value in the data structure will indicate the >> exact sub-command to be executed. >> >> The sets are against the latest netdev-2.4 and net-drivers-2.5-exp trees. > > > > I don't disagree with the overall goal of these patches, but I think we > might need to pause a bit, and consider how best to configure, add, and > remove bonding interfaces, if we are coming up with a new interface. > > For configuration tasks that occur outside the scope of a single bonding > interface (i.e. a single struct net_device), you need a separate entity > from a socket ioctl. It's not ideal at all to configure N objects using > a special ioctl ... when opening one of said objects :) Why is it not ideal? Are ioctl calls significantly less expensive than accessing a character device? It does not seem easier to program on either side, and wouldn't users have to do a mknod or something like that to get their char device to appear? I would not look forward to dealing with framing issues in the kernel either, and for 'reading' information, it seems there could be some tricky code dealing with queueing up the message for user-space and then *hoping* that they did a 'read' before you had to clean up the message and/or over-write it. > I would suggest a simple character device (misc_register), and let the > userland application configure settings unrelated to a single object. > > For a configuring state related to a _single_ bonding interface (i.e. a > single net_device), socket ioctls are OK. From a user-space coding perspective, it would be easier to just have one socket to do all the ioctl calls. I really don't see even an aesthetic reason to artificially restrict an socket ioctl to only function on a single thing. Please don't tell me you also want to change ethtool to not use multiplexed ioctl calls as it does now? (I like the ethtool interface very much and in fact, if I were starting over, I'd implement VLAN ioctls as an ethtool command...) Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From scott.feldman@intel.com Mon Jan 12 09:43:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 09:43:59 -0800 (PST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CHhh6H014953 for ; Mon, 12 Jan 2004 09:43:44 -0800 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0CHjYBX024462; Mon, 12 Jan 2004 17:45:35 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0CHgJfZ001057; Mon, 12 Jan 2004 17:44:05 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011209432416354 ; Mon, 12 Jan 2004 09:43:24 -0800 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 12 Jan 2004 09:43:24 -0800 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: [2.4] e1000 leaking pci mappings on rx errors? Date: Mon, 12 Jan 2004 09:43:23 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [2.4] e1000 leaking pci mappings on rx errors? Thread-Index: AcPZKyNympxkZGUTTKWQk24rh4KF4AAB3txA From: "Feldman, Scott" To: , Cc: "cramerj" X-OriginalArrivalTime: 12 Jan 2004 17:43:24.0087 (UTC) FILETIME=[93B04C70:01C3D933] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0CHhh6H014953 X-archive-position: 2360 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 Content-Length: 359 Lines: 10 > We have a machine here (running a RHEL 2.4.21-based kernel), > that started showing leakage of PCI mappings when the driver > was upgraded from 5.1.11 to 5.2.20. Olof, please try 5.1.13 and 5.2.16 from sf.net/projects/e1000 to help narrow the diff. I'm not seeing anything obvious in the diff between 5.1.11 and 5.2.20 that would explain this. -scott From dlstevens@us.ibm.com Mon Jan 12 10:55:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 10:55:17 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CIsu6H025328 for ; Mon, 12 Jan 2004 10:55:03 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0CIsmrE361208; Mon, 12 Jan 2004 13:54:48 -0500 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0CIslqY124678; Mon, 12 Jan 2004 11:54:47 -0700 Importance: Normal Sensitivity: Subject: Re: MLD problems (again) [PATCH] To: Takashi Hibi Cc: netdev@oss.sgi.com, davem@redhat.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Mon, 12 Jan 2004 10:54:43 -0800 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/12/2004 11:54:47 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE48ADFF4CF588f9e8a93df938690918c07BBE48ADFF4CF58" Content-Disposition: inline X-archive-position: 2361 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 7026 Lines: 179 --0__=07BBE48ADFF4CF588f9e8a93df938690918c07BBE48ADFF4CF58 Content-type: text/plain; charset=US-ASCII Takashi, The patch I sent was for 2.6.1, but it should also apply to 2.4 line kernels and fix the problem. If you have problems getting it to apply in 2.4, let me know what version and I can provide you a patch specific for that kernel. +-DLS Takashi Hibi on 01/12/2004 03:04:48 AM To: David Stevens/Beaverton/IBM@IBMUS cc: netdev@oss.sgi.com, davem@redhat.com Subject: Re: MLD problems (again) [PATCH] David, Thank you for the patch. But at least it doesn't solve the problem for 2.4 line kernel. I will also test with 2.6.1 later. Regards, Takashi Hibi > > > > > Takashi, > I believe the patch below will fix the problem you > had with MCAST_JOIN_SOURCE_GROUP not sending a > report. There was a typo in the source filter switching that did > two deletes, rather than an delete and an add. > > Dave, > Although IGMPv3 didn't have any problems, this patch > also re-arranges the order of the filter changes. I think it's cleaner > to add the new one first and then delete the old one, rather than > having a small window with no filter set. So, this is a bug fix for MLD > and a code clean-up for IGMPv3. > This bug and patch should also apply to the 2.4 line. > > +-DLS > > [included in-line for viewing and as an attachment for unmangled > whitespace] > > --- linux-2.6.1/net/ipv6/mcast.c 2004-01-08 22:59:56.000000000 -0800 > +++ linux-2.6.1F1/net/ipv6/mcast.c 2004-01-11 21:06:05.000000000 -0800 > @@ -372,9 +372,9 @@ > goto done; > } else if (pmc->sfmode != omode) { > /* allow mode switches for empty-set filters */ > + ip6_mc_add_src(idev, group, omode, 0, 0, 0); > ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); > pmc->sfmode = omode; > - ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); > } > > psl = pmc->sflist; > --- linux-2.6.1/net/ipv4/igmp.c 2004-01-08 23:00:12.000000000 -0800 > +++ linux-2.6.1F1/net/ipv4/igmp.c 2004-01-11 21:27:41.000000000 -0800 > @@ -1749,11 +1749,10 @@ > goto done; > } else if (pmc->sfmode != omode) { > /* allow mode switches for empty-set filters */ > + ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, omode, 0, 0, 0); > ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, > 0, 0); > pmc->sfmode = omode; > - ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, > - 0, 0); > } > > psl = pmc->sflist; > > (See attached file: 2.6.1MLD.patch) --0__=07BBE48ADFF4CF588f9e8a93df938690918c07BBE48ADFF4CF58 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Takashi,
The patch I sent was for 2.6.1, but it should also apply to
2.4 line kernels and fix the problem. If you have problems getting
it to apply in 2.4, let me know what version and I can provide you
a patch specific for that kernel.

+-DLS

To: David Stevens/Beaverton/IBM@IBMUS
cc: netdev@oss.sgi.com, davem@redhat.com
Subject: Re: MLD problems (again) [PATCH]



David,

Thank you for the patch.
But at least it doesn't solve the problem for 2.4 line kernel.
I will also test with 2.6.1 later.

Regards,
Takashi Hibi

>
>
>
>
> Takashi,
>       I believe the patch below will fix the problem you
> had with MCAST_JOIN_SOURCE_GROUP not sending a
> report. There was a typo in the source filter switching that did
> two deletes, rather than an delete and an add.
>
> Dave,
>       Although IGMPv3 didn't have any problems, this patch
> also re-arranges the order of the filter changes. I think it's cleaner
> to add the new one first and then delete the old one, rather than
> having a small window with no filter set. So, this is a bug fix for MLD
> and a code clean-up for IGMPv3.
>       This bug and patch should also apply to the 2.4 line.
>
>                         +-DLS
>
> [included in-line for viewing and as an attachment for unmangled
>       whitespace]
>
> --- linux-2.6.1/net/ipv6/mcast.c    2004-01-08 22:59:56.000000000 -0800
> +++ linux-2.6.1F1/net/ipv6/mcast.c  2004-01-11 21:06:05.000000000 -0800
> @@ -372,9 +372,9 @@
>                   goto done;
>       } else if (pmc->sfmode != omode) {
>             /* allow mode switches for empty-set filters */
> +           ip6_mc_add_src(idev, group, omode, 0, 0, 0);
>             ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0);
>             pmc->sfmode = omode;
> -           ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0);
>       }
>
>       psl = pmc->sflist;
> --- linux-2.6.1/net/ipv4/igmp.c     2004-01-08 23:00:12.000000000 -0800
> +++ linux-2.6.1F1/net/ipv4/igmp.c   2004-01-11 21:27:41.000000000 -0800
> @@ -1749,11 +1749,10 @@
>                   goto done;
>       } else if (pmc->sfmode != omode) {
>             /* allow mode switches for empty-set filters */
> +           ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, omode, 0, 0, 0);
>             ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0,
>                   0, 0);
>             pmc->sfmode = omode;
> -           ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0,
> -                 0, 0);
>       }
>
>       psl = pmc->sflist;
>
> (See attached file: 2.6.1MLD.patch)




--0__=07BBE48ADFF4CF588f9e8a93df938690918c07BBE48ADFF4CF58-- From linux-netdev@gmane.org Mon Jan 12 12:00:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 12:01:06 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CK0c6H027857 for ; Mon, 12 Jan 2004 12:00:41 -0800 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Ag8Em-0004w5-00 for ; Mon, 12 Jan 2004 21:00:36 +0100 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 1Ag8Dl-0004uv-00 for ; Mon, 12 Jan 2004 20:59:33 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Ag8Dl-0000Cd-00 for ; Mon, 12 Jan 2004 20:59:33 +0100 From: Alessandro Bono Subject: Broadcom NetXtreme BCM5788 severe performance problem Date: Mon, 12 Jan 2004 20:59:52 +0100 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1181838.TEsOKFeMFJ" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org User-Agent: KNode/0.7.2 X-archive-position: 2362 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sandro@cantina.dyndns.org Precedence: bulk X-list: netdev Content-Length: 60817 Lines: 2075 --nextPart1181838.TEsOKFeMFJ Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8Bit Hi I have an Msi mobo with an integrated Broadcom NetXtreme gigabit ehternet that has big performance problem i tried 2.4.x with tg3 and with broadcom driver and 2.6.x with the same result a simple ftp transfer cause a 70% cpu usage and 6Mb/s, same hardware with a cheap 8139too can transfer 10-11 Mb/s without notable cpu usage this performance with lftp, with konqueror 1-2Mb and 100% cpu usage lan is 100Mbit full duplex i tried also to activate tso with ethtool and disactivate napi (with patch posted on this ml) but without any luck any hint? thanks -Ale --nextPart1181838.TEsOKFeMFJ Content-Type: text/plain; name=".config" Content-Transfer-Encoding: 8Bit Content-Disposition: attachment; filename=".config" # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_CLEAN_COMPILE is not set # CONFIG_STANDALONE is not set CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MELAN is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y # CONFIG_X86_4G is not set # CONFIG_X86_SWITCH_PAGETABLES is not set # CONFIG_X86_4G_VM_LAYOUT is not set # CONFIG_X86_UACCESS_INDIRECT is not set # CONFIG_X86_HIGH_ENTRY is not set CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_EDD=m CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_DISK=y CONFIG_PM_DISK_PARTITION="" # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y # CONFIG_ACPI_FAN is not set CONFIG_ACPI_PROCESSOR=y # CONFIG_ACPI_THERMAL is not set # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_ACPI_RELAXED_AML is not set CONFIG_X86_PM_TIMER=y # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_USE_VECTOR=y CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_MISC=m # # Device Drivers # # # Generic Driver Options # CONFIG_FW_LOADER=m # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m # CONFIG_PARPORT_SERIAL is not set # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # # CONFIG_ISAPNP is not set CONFIG_PNPBIOS=y CONFIG_PNPBIOS_PROC_FS=y # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # CONFIG_LBD is not set # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=m CONFIG_BLK_DEV_IDE=m # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=m # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_IDEDISK_STROKE is not set CONFIG_BLK_DEV_IDECD=m # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set CONFIG_IDE_TASKFILE_IO=y # # IDE chipset support/bugfixes # # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_IDEPNP is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set # CONFIG_IDEDMA_PCI_WIP is not set CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=m CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_DMA_NONPCI is not set # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y CONFIG_MAX_SD_DISKS=256 # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_REPORT_LUNS is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_MEGARAID is not set CONFIG_SCSI_SATA=y # CONFIG_SCSI_SATA_SVW is not set # CONFIG_SCSI_ATA_PIIX is not set # CONFIG_SCSI_SATA_PROMISE is not set # CONFIG_SCSI_SATA_SIL is not set CONFIG_SCSI_SATA_VIA=y # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID5=m CONFIG_MD_MULTIPATH=m CONFIG_BLK_DEV_DM=m CONFIG_DM_IOCTL_V4=y # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # CONFIG_IEEE1394=m # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set # CONFIG_IEEE1394_OUI_DB is not set # # Device Drivers # CONFIG_IEEE1394_PCILYNX=m CONFIG_IEEE1394_OHCI1394=m # # Protocol Drivers # CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_SBP2=m # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set CONFIG_IEEE1394_ETH1394=m CONFIG_IEEE1394_DV1394=m CONFIG_IEEE1394_RAWIO=m CONFIG_IEEE1394_CMP=m CONFIG_IEEE1394_AMDTP=m # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK_DEV=y CONFIG_UNIX=y CONFIG_NET_KEY=m CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set # CONFIG_IPV6 is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m # CONFIG_IP_NF_NAT_LOCAL is not set CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set CONFIG_XFRM=y CONFIG_XFRM_USER=m # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IPV6_SCTP__=y # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_EQUALIZER=m CONFIG_TUN=m CONFIG_ETHERTAP=m # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=m # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_HP100 is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set # CONFIG_E100 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set CONFIG_NE2K_PCI=m # CONFIG_8139CP is not set CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set CONFIG_8139_RXBUF_IDX=2 # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SK98LIN is not set CONFIG_TIGON3=m # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set CONFIG_PLIP=m CONFIG_PPP=m # CONFIG_PPP_MULTILINK is not set CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m # CONFIG_PPPOE is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # CONFIG_NETCONSOLE is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # Bluetooth support # # CONFIG_BT is not set # CONFIG_KGDBOE is not set # CONFIG_NETPOLL is not set # CONFIG_NETPOLL_RX is not set # CONFIG_NETPOLL_TRAP is not set # CONFIG_NET_POLL_CONTROLLER is not set # # ISDN subsystem # # CONFIG_ISDN_BOOL is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=m # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # CONFIG_GAMEPORT=m CONFIG_SOUND_GAMEPORT=m # CONFIG_GAMEPORT_NS558 is not set # CONFIG_GAMEPORT_L4 is not set CONFIG_GAMEPORT_EMU10K1=m # CONFIG_GAMEPORT_VORTEX is not set # CONFIG_GAMEPORT_FM801 is not set # CONFIG_GAMEPORT_CS461x is not set CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=m # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y # CONFIG_MOUSE_SERIAL is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m CONFIG_INPUT_UINPUT=m # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=m CONFIG_SERIAL_8250_ACPI=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y # CONFIG_SERIAL_8250_MANY_PORTS is not set CONFIG_SERIAL_8250_SHARE_IRQ=y # CONFIG_SERIAL_8250_DETECT_IRQ is not set # CONFIG_SERIAL_8250_MULTIPORT is not set # CONFIG_SERIAL_8250_RSA is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=m CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set # CONFIG_PPDEV is not set # CONFIG_TIPAR is not set # # I2C support # CONFIG_I2C=m CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCF=m # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_ELEKTOR is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PHILIPSPAR is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_PROSAVAGE is not set # CONFIG_I2C_SAVAGE4 is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set CONFIG_I2C_VIA=m CONFIG_I2C_VIAPRO=m # CONFIG_I2C_VOODOO3 is not set # # I2C Hardware Sensors Chip support # CONFIG_I2C_SENSOR=m CONFIG_SENSORS_ADM1021=m CONFIG_SENSORS_EEPROM=m CONFIG_SENSORS_IT87=m CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM78=m CONFIG_SENSORS_LM83=m CONFIG_SENSORS_LM85=m CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_W83781D=m # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_QIC02_TAPE is not set # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set CONFIG_HW_RANDOM=m CONFIG_NVRAM=m CONFIG_RTC=m CONFIG_GEN_RTC=m CONFIG_GEN_RTC_X=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=m # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set # CONFIG_AGP_INTEL is not set # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set CONFIG_AGP_VIA=m CONFIG_DRM=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_GAMMA is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=m # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_MWAVE is not set CONFIG_RAW_DRIVER=m CONFIG_MAX_RAW_DEVS=256 CONFIG_HANGCHECK_TIMER=m # # Multimedia devices # CONFIG_VIDEO_DEV=m # # Video For Linux # # # Video Adapters # CONFIG_VIDEO_BT848=m # CONFIG_VIDEO_BWQCAM is not set # CONFIG_VIDEO_CQCAM is not set # CONFIG_VIDEO_W9966 is not set # CONFIG_VIDEO_CPIA is not set # CONFIG_VIDEO_SAA5249 is not set # CONFIG_TUNER_3036 is not set # CONFIG_VIDEO_STRADIS is not set # CONFIG_VIDEO_ZORAN is not set # CONFIG_VIDEO_ZR36120 is not set # CONFIG_VIDEO_SAA7134 is not set # CONFIG_VIDEO_MXB is not set # CONFIG_VIDEO_DPC is not set # CONFIG_VIDEO_HEXIUM_ORION is not set # CONFIG_VIDEO_HEXIUM_GEMINI is not set # # Radio Adapters # # CONFIG_RADIO_GEMTEK_PCI is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set CONFIG_VIDEO_TUNER=m CONFIG_VIDEO_BUF=m CONFIG_VIDEO_BTCX=m # # Graphics support # CONFIG_FB=y # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set # CONFIG_FB_VESA is not set CONFIG_VIDEO_SELECT=y # CONFIG_FB_HGA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_MATROX is not set CONFIG_FB_RADEON=m # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=m CONFIG_PCI_CONSOLE=y CONFIG_FONTS=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # CONFIG_FONT_6x11 is not set # CONFIG_FONT_PEARL_8x8 is not set # CONFIG_FONT_ACORN_8x8 is not set # CONFIG_FONT_MINI_4x6 is not set # CONFIG_FONT_SUN8x16 is not set # CONFIG_FONT_SUN12x22 is not set # # Logo configuration # CONFIG_LOGO=y CONFIG_LOGO_LINUX_MONO=y CONFIG_LOGO_LINUX_VGA16=y CONFIG_LOGO_LINUX_CLUT224=y # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m CONFIG_SND_VERBOSE_PRINTK=y # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTPAV=m CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m # # PCI devices # # CONFIG_SND_ALI5451 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS4281 is not set CONFIG_SND_EMU10K1=m # CONFIG_SND_KORG1212 is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_SONICVIBES is not set CONFIG_SND_VIA82XX=m # CONFIG_SND_VX222 is not set # # ALSA USB devices # # CONFIG_SND_USB_AUDIO is not set # # Open Sound System # CONFIG_SOUND_PRIME=m # CONFIG_SOUND_BT878 is not set # CONFIG_SOUND_CMPCI is not set # CONFIG_SOUND_EMU10K1 is not set # CONFIG_SOUND_FUSION is not set # CONFIG_SOUND_CS4281 is not set # CONFIG_SOUND_ES1370 is not set # CONFIG_SOUND_ES1371 is not set # CONFIG_SOUND_ESSSOLO1 is not set # CONFIG_SOUND_MAESTRO is not set # CONFIG_SOUND_MAESTRO3 is not set # CONFIG_SOUND_ICH is not set # CONFIG_SOUND_SONICVIBES is not set # CONFIG_SOUND_TRIDENT is not set # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set CONFIG_SOUND_VIA82CXXX=m CONFIG_MIDI_VIA82CXXX=y # CONFIG_SOUND_OSS is not set CONFIG_SOUND_TVMIXER=m # CONFIG_SOUND_ALI5455 is not set # CONFIG_SOUND_FORTE is not set # CONFIG_SOUND_RME96XX is not set # CONFIG_SOUND_AD1980 is not set # # USB support # CONFIG_USB=m # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m CONFIG_USB_OHCI_HCD=m CONFIG_USB_UHCI_HCD=m # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH_TTY is not set # CONFIG_USB_MIDI is not set CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set CONFIG_USB_STORAGE_HP8200e=y # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # # USB Human Interface Devices (HID) # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_XPAD is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set CONFIG_USB_SCANNER=m # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # CONFIG_USB_VICAM is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_KONICAWC is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_PWC is not set # CONFIG_USB_SE401 is not set # CONFIG_USB_STV680 is not set # CONFIG_USB_W9968CF is not set # # USB Network adaptors # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set CONFIG_USB_USBNET=m # # USB Host-to-Host Cables # # CONFIG_USB_AN2720 is not set # CONFIG_USB_BELKIN is not set # CONFIG_USB_GENESYS is not set # CONFIG_USB_NET1080 is not set CONFIG_USB_PL2301=y # # Intelligent USB Devices/Gadgets # # CONFIG_USB_ARMLINUX is not set # CONFIG_USB_EPSON2888 is not set # CONFIG_USB_ZAURUS is not set # CONFIG_USB_CDCETHER is not set # # USB Network Adapters # # CONFIG_USB_AX8817X is not set # # USB port drivers # # CONFIG_USB_USS720 is not set # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y # CONFIG_USB_SERIAL_BELKIN is not set # CONFIG_USB_SERIAL_WHITEHEAT is not set # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set # CONFIG_USB_SERIAL_EMPEG is not set # CONFIG_USB_SERIAL_FTDI_SIO is not set # CONFIG_USB_SERIAL_VISOR is not set # CONFIG_USB_SERIAL_IPAQ is not set # CONFIG_USB_SERIAL_IR is not set # CONFIG_USB_SERIAL_EDGEPORT is not set # CONFIG_USB_SERIAL_EDGEPORT_TI is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set # CONFIG_USB_SERIAL_KEYSPAN is not set # CONFIG_USB_SERIAL_KLSI is not set # CONFIG_USB_SERIAL_KOBIL_SCT is not set # CONFIG_USB_SERIAL_MCT_U232 is not set CONFIG_USB_SERIAL_PL2303=m # CONFIG_USB_SERIAL_SAFE is not set # CONFIG_USB_SERIAL_CYBERJACK is not set # CONFIG_USB_SERIAL_XIRCOM is not set # CONFIG_USB_SERIAL_OMNINET is not set # # USB Miscellaneous drivers # # CONFIG_USB_TIGL is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_BRLVGER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_TEST is not set # CONFIG_USB_GADGET is not set # # File systems # CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y # CONFIG_JFS_DEBUG is not set CONFIG_JFS_STATISTICS=y CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=m # CONFIG_XFS_RT is not set # CONFIG_XFS_QUOTA is not set CONFIG_XFS_POSIX_ACL=y CONFIG_MINIX_FS=m # CONFIG_ROMFS_FS is not set # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=m CONFIG_UDF_FS=m # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y # CONFIG_DEVFS_FS is not set CONFIG_DEVPTS_FS=y CONFIG_DEVPTS_FS_XATTR=y CONFIG_DEVPTS_FS_SECURITY=y CONFIG_TMPFS=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=m CONFIG_NFS_V3=y # CONFIG_NFS_V4 is not set CONFIG_NFS_DIRECTIO=y CONFIG_NFSD=m CONFIG_NFSD_V3=y # CONFIG_NFSD_V4 is not set # CONFIG_NFSD_TCP is not set CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_RPCSEC_GSS_KRB5=m CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set CONFIG_CIFS=m # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set CONFIG_LDM_PARTITION=y # CONFIG_LDM_DEBUG is not set # CONFIG_NEC98_PARTITION is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_EFI_PARTITION is not set # # Native Language Support # CONFIG_NLS=m CONFIG_NLS_DEFAULT="iso8859-15" CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_FRAME_POINTER is not set CONFIG_X86_EXTRA_IRQS=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # # CONFIG_SECURITY is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_DEFLATE=m # CONFIG_CRYPTO_TEST is not set # # Library routines # CONFIG_CRC32=m CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_X86_BIOS_REBOOT=y CONFIG_PC=y --nextPart1181838.TEsOKFeMFJ Content-Type: text/plain; name="dmesg" Content-Transfer-Encoding: 8Bit Content-Disposition: attachment; filename="dmesg" (ACPI data) BIOS-e820: 000000001fff8000 - 0000000020000000 (ACPI NVS) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) 511MB LOWMEM available. found SMP MP-table at 000fb990 hm, page 000fb000 reserved twice. hm, page 000fc000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f7000 reserved twice. On node 0 totalpages: 131056 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 126960 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. ACPI: RSDP (v000 AMI ) @ 0x000faa00 ACPI: RSDT (v001 AMIINT VIA_K7 0x00000010 MSFT 0x00000097) @ 0x1fff0000 ACPI: FADT (v001 AMIINT VIA_K7 0x00000011 MSFT 0x00000097) @ 0x1fff0030 ACPI: MADT (v001 AMIINT VIA_K7 0x00000009 MSFT 0x00000097) @ 0x1fff00c0 ACPI: DSDT (v001 VIA VIA_K7 0x00001000 MSFT 0x0100000d) @ 0x00000000 ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 16 ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0]) IOAPIC[0]: Assigned apic_id 2 IOAPIC[0]: apic_id 2, version 3, address 0xfec00000, IRQ 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI BALANCE SET Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Building zonelist for node : 0 current: c02c0a60 current->thread_info: c0324000 Initializing CPU#0 Kernel command line: BOOT_IMAGE=2.6.1-mm2 ro root=806 PID hash table entries: 2048 (order 11: 16384 bytes) Detected 2004.482 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Memory: 515736k/524224k available (1537k kernel code, 7740k reserved, 653k data, 152k init, 0k highmem) zapping low mappings. Calibrating delay loop... 1986.56 BogoMIPS Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 0383fbff c1c3fbff 00000000 00000000 CPU: After vendor identify, caps: 0383fbff c1c3fbff 00000000 00000000 CPU: CLK_CTL MSR was 6003d22f. Reprogramming to 2003d22f CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After all inits, caps: 0383fbff c1c3fbff 00000000 00000020 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: AMD Athlon(tm) XP 2400+ stepping 01 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX enabled ExtINT on CPU#0 ESR value before enabling vector: 00000080 ESR value after enabling vector: 00000000 ENABLING IO-APIC IRQs init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=0x31 pin1=2 pin2=-1 Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 2004.0307 MHz. ..... host bus clock speed is 267.0240 MHz. NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfdb11, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20031203 IOAPIC[0]: Set PCI routing entry (2-9 -> 0x71 -> IRQ 9 Mode:1 Active:1) ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Power Resource [URP1] (off) ACPI: Power Resource [URP2] (off) ACPI: Power Resource [FDDP] (off) ACPI: Power Resource [LPTP] (off) ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay PnPBIOS: Scanning system for PnP BIOS support... PnPBIOS: Found PnP BIOS installation structure at 0xc00f7900 PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0x67ab, dseg 0xf0000 PnPBIOS: 14 nodes reported by PnP BIOS; 14 recorded by driver SCSI subsystem initialized IOAPIC[0]: Set PCI routing entry (2-16 -> 0xa9 -> IRQ 16 Mode:1 Active:1) 00:00:01[A] -> 2-16 -> IRQ 169 IOAPIC[0]: Set PCI routing entry (2-17 -> 0xb1 -> IRQ 17 Mode:1 Active:1) 00:00:01[B] -> 2-17 -> IRQ 177 IOAPIC[0]: Set PCI routing entry (2-20 -> 0xb9 -> IRQ 20 Mode:1 Active:1) 00:00:11[A] -> 2-20 -> IRQ 185 IOAPIC[0]: Set PCI routing entry (2-22 -> 0xc1 -> IRQ 22 Mode:1 Active:1) 00:00:11[C] -> 2-22 -> IRQ 193 Pin 2-16 already programmed Pin 2-17 already programmed IOAPIC[0]: Set PCI routing entry (2-18 -> 0xc9 -> IRQ 18 Mode:1 Active:1) 00:00:05[C] -> 2-18 -> IRQ 201 IOAPIC[0]: Set PCI routing entry (2-19 -> 0xd1 -> IRQ 19 Mode:1 Active:1) 00:00:05[D] -> 2-19 -> IRQ 209 Pin 2-17 already programmed Pin 2-18 already programmed Pin 2-19 already programmed Pin 2-16 already programmed Pin 2-19 already programmed Pin 2-16 already programmed Pin 2-17 already programmed Pin 2-18 already programmed Pin 2-18 already programmed Pin 2-19 already programmed Pin 2-16 already programmed Pin 2-17 already programmed Pin 2-17 already programmed Pin 2-18 already programmed Pin 2-19 already programmed Pin 2-16 already programmed Pin 2-19 already programmed Pin 2-17 already programmed IOAPIC[0]: Set PCI routing entry (2-21 -> 0xd9 -> IRQ 21 Mode:1 Active:1) 00:00:10[A] -> 2-21 -> IRQ 217 Pin 2-21 already programmed Pin 2-21 already programmed Pin 2-21 already programmed IOAPIC[0]: Set PCI routing entry (2-23 -> 0xe1 -> IRQ 23 Mode:1 Active:1) 00:00:12[A] -> 2-23 -> IRQ 225 Pin 2-18 already programmed Pin 2-20 already programmed Pin 2-20 already programmed Pin 2-20 already programmed Pin 2-20 already programmed number of MP IRQ sources: 15. number of IO-APIC #2 registers: 24. testing the IO APIC....................... IO APIC #2...... .... register #00: 02000000 ....... : physical APIC id: 02 ....... : Delivery Type: 0 ....... : LTS : 0 .... register #01: 00178003 ....... : max redirection entries: 0017 ....... : PRQ implemented: 1 ....... : IO APIC version: 0003 .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 1 0 0 0 0 0 0 00 01 001 01 0 0 0 0 0 1 1 39 02 001 01 0 0 0 0 0 1 1 31 03 001 01 0 0 0 0 0 1 1 41 04 001 01 0 0 0 0 0 1 1 49 05 001 01 0 0 0 0 0 1 1 51 06 001 01 0 0 0 0 0 1 1 59 07 001 01 0 0 0 0 0 1 1 61 08 001 01 0 0 0 0 0 1 1 69 09 001 01 0 1 0 1 0 1 1 71 0a 001 01 0 0 0 0 0 1 1 79 0b 001 01 0 0 0 0 0 1 1 81 0c 001 01 0 0 0 0 0 1 1 89 0d 001 01 0 0 0 0 0 1 1 91 0e 001 01 0 0 0 0 0 1 1 99 0f 001 01 0 0 0 0 0 1 1 A1 10 001 01 1 1 0 1 0 1 1 A9 11 001 01 1 1 0 1 0 1 1 B1 12 001 01 1 1 0 1 0 1 1 C9 13 001 01 1 1 0 1 0 1 1 D1 14 001 01 1 1 0 1 0 1 1 B9 15 001 01 1 1 0 1 0 1 1 D9 16 001 01 1 1 0 1 0 1 1 C1 17 001 01 1 1 0 1 0 1 1 E1 IRQ to pin mappings: IRQ0 -> 0:2 IRQ1 -> 0:1 IRQ3 -> 0:3 IRQ4 -> 0:4 IRQ5 -> 0:5 IRQ6 -> 0:6 IRQ7 -> 0:7 IRQ8 -> 0:8 IRQ9 -> 0:9-> 0:9 IRQ10 -> 0:10 IRQ11 -> 0:11 IRQ12 -> 0:12 IRQ13 -> 0:13 IRQ14 -> 0:14 IRQ15 -> 0:15 IRQ16 -> 0:16 IRQ17 -> 0:17 IRQ18 -> 0:18 IRQ19 -> 0:19 IRQ20 -> 0:20 IRQ21 -> 0:21 IRQ22 -> 0:22 IRQ23 -> 0:23 .................................... done. PCI: Using ACPI for IRQ routing PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off' Machine check exception polling timer started. ikconfig 0.7 with /proc/config* Initializing Cryptographic API PCI: Via IRQ fixup for 0000:00:10.3, from 10 to 9 PCI: Via IRQ fixup for 0000:00:10.2, from 10 to 9 PCI: Via IRQ fixup for 0000:00:10.1, from 11 to 9 PCI: Via IRQ fixup for 0000:00:10.0, from 11 to 9 ACPI: Power Button (FF) [PWRF] ACPI: Sleep Button (CM) [SLPB] ACPI: Processor [CPU1] (supports C1) pty: 256 Unix98 ptys configured libata version 0.81 loaded. sata_via version 0.11 ata1: SATA max UDMA/133 cmd 0xE800 ctl 0xE402 bmdma 0xD800 irq 185 ata2: SATA max UDMA/133 cmd 0xE000 ctl 0xDC02 bmdma 0xD808 irq 185 ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4003 85:7c69 86:3e01 87:4003 88:407f ata1: dev 0 ATA, max UDMA/133, 320173056 sectors (lba48) ata1: dev 0 configured for UDMA/133 scsi0 : sata_via ATA: abnormal status 0x7F on port 0xE007 ata2: thread exiting scsi1 : sata_via Using anticipatory io scheduler Vendor: ATA Model: Maxtor 6Y160M0 Rev: 0.81 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 320173056 512-byte hdwr sectors (163929 MB) SCSI device sda: drive cache: write through sda: sda1 sda2 sda3 < sda5 sda6 sda7 > Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 mice: PS/2 mouse device common for all mice serio: i8042 AUX port at 0x60,0x64 irq 12 input: PS2++ Logitech Wheel Mouse on isa0060/serio1 serio: i8042 KBD port at 0x60,0x64 irq 1 input: AT Translated Set 2 keyboard on isa0060/serio0 NET: Registered protocol family 2 IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 32768 bind 65536) NET: Registered protocol family 1 NET: Registered protocol family 17 PM: Reading pmdisk image. PM: Resume from disk failed. ACPI: (supports S0 S1 S4 S5) kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 152k freed Adding 1951856k swap on /dev/sda7. Priority:-1 extents:1 EXT3 FS on sda6, internal journal Real Time Clock Driver v1.12 Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected VIA KT400/KT400A/KT600 chipset agpgart: Maximum main memory to use for agp memory: 439M agpgart: AGP aperture is 128M @ 0xe0000000 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 0000:00:0f.1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1 ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:pio hda: HL-DT-ST GCE-8520B, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hdc: ASUS DVD-ROM E612, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 Module via82cxxx cannot be unloaded due to unsafe usage in include/linux/module.h:483 Linux video capture interface: v1.00 bttv: driver version 0.9.12 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Bt8xx card found (0). bttv0: Bt878 (rev 17) at 0000:00:07.0, irq: 209, latency: 32, mmio: 0xdfdfe000 bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb bttv0: using: Hauppauge (bt878) [card=10,autodetected] bttv0: Hauppauge/Voodoo msp34xx: reset line init [5] registering 0-0050 bttv0: Hauppauge eeprom: model=44354, tuner=Philips FM1216 (5), radio=yes bttv0: using tuner=5 bttv0: i2c: checking for MSP34xx @ 0x80... found msp34xx: init: chip=MSP3415G-B8 +nicam +simple +radio msp3410: daemon started registering 0-0040 bttv0: i2c: checking for TDA9875 @ 0xb0... not found bttv0: i2c: checking for TDA7432 @ 0x8a... not found tvaudio: TV audio decoder + audio/video mux driver tvaudio: known chips: tda9840,tda9873h,tda9874h/a,tda9850,tda9855,tea6300,tea6420,tda8425,pic16c54 (PV951),ta8874z tuner: chip found @ 0xc2 tuner: type set to 5 (Philips PAL_BG (FI1216 and compatibles)) registering 0-0061 bttv0: registered device video0 bttv0: registered device vbi0 bttv0: registered device radio0 bttv0: PLL: 28636363 => 35468950 .. ok tg3.c:v2.5 (December 22, 2003) eth0: Tigon3 [partno(BCM95705A50) rev 3003 PHY(5705)] (PCI:33MHz:32-bit) 10/100/1000BaseT Ethernet 00:0c:76:57:8d:7a device-mapper: 4.0.0-ioctl (2003-06-04) initialised: dm@uk.sistina.com kjournald starting. Commit interval 5 seconds EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on dm-1, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on dm-0, internal journal EXT3-fs: mounted filesystem with ordered data mode. NTFS driver 2.1.5 [Flags: R/W MODULE]. NTFS volume version 3.1. drivers/usb/core/usb.c: registered new driver usbfs drivers/usb/core/usb.c: registered new driver hub ehci_hcd 0000:00:10.4: EHCI Host Controller ehci_hcd 0000:00:10.4: irq 217, pci mem e09dd600 ehci_hcd 0000:00:10.4: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:10.4: USB 2.0 enabled, EHCI 1.00, driver 2003-Jun-13 hub 1-0:1.0: USB hub found hub 1-0:1.0: 8 ports detected ohci_hcd: 2003 Oct 13 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) ohci_hcd: block sizes: ed 64 td 64 drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver v2.1 uhci_hcd 0000:00:10.0: UHCI Host Controller uhci_hcd 0000:00:10.0: irq 217, io base 0000bc00 uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected uhci_hcd 0000:00:10.1: UHCI Host Controller uhci_hcd 0000:00:10.1: irq 217, io base 0000c000 uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 3 hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected uhci_hcd 0000:00:10.2: UHCI Host Controller uhci_hcd 0000:00:10.2: irq 217, io base 0000c400 uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 4 hub 4-0:1.0: USB hub found hub 4-0:1.0: 2 ports detected uhci_hcd 0000:00:10.3: UHCI Host Controller uhci_hcd 0000:00:10.3: irq 217, io base 0000c800 uhci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 5 hub 5-0:1.0: USB hub found hub 5-0:1.0: 2 ports detected request_module: failed /sbin/modprobe -- net-pf-20. error = 256 tg3: eth0: Link is up at 100 Mbps, full duplex. tg3: eth0: Flow control is on for TX and on for RX. nfs warning: mount version older than kernel nfs warning: mount version older than kernel request_module: failed /sbin/modprobe -- char-major-4-64. error = 256 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A --nextPart1181838.TEsOKFeMFJ Content-Type: text/plain; name="lspci.log" Content-Transfer-Encoding: 8Bit Content-Disposition: attachment; filename="lspci.log" 00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400 AGP] Host Bridge (rev 80) Subsystem: VIA Technologies, Inc.: Unknown device 0000 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:06.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 06) Subsystem: Creative Labs CT4832 SBLive! Value Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- ; Mon, 12 Jan 2004 12:24:34 -0800 Received: from localhost (cadence@localhost) by rubycon.man.szczecin.pl (8.10.0/8.10.0) with ESMTP id i0CKO1Y20070; Mon, 12 Jan 2004 21:24:07 +0100 Date: Mon, 12 Jan 2004 21:24:01 +0100 (CET) From: Tomasz Grabowski To: Paul.Russell@rustcorp.com.au cc: Alan.Cox@linux.org, netdev@oss.sgi.com, jmorris@intercode.com.au, cert@cert.org Subject: Security bug in 2.2 kernel series Message-ID: X-Hidden: The Progress only comes through struggle MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2363 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cadence@rubycon.man.szczecin.pl Precedence: bulk X-list: netdev Content-Length: 3328 Lines: 76 Hello. I found security bug in TCP/IP stack implementation in Linux 2.2. kernel series. Short description: Machine A is sending SYN packet to machine B, which is running linux kernel version 2.2. Machine B is responding with SYN+ACK packet and is waiting for ACK packet from machine A. So far everything is good. Now, machine A is sending another SYN packet with same source and destination address and same source and destination port. Machine B should respond with RST packet and drop that connection. Unfortunatelly, kernel 2.2 is accepting that second SYN packet, setting up another socket for it in SYN_RECV state and responding with another SYN+ACK packet which differ from the original one only by another Initial Sequence Number. Now, machine A can send many such SYN packets, and machine B will set up sockets for every one of them. My first thought was that it could be used for birthday paradox attacks for ISN guessing, but it turned out that only the first generated sequence number (i.e. the first SYN+ACK generated in reply to first SYN packet) is the right one. If you will send ACK packet with sequence number generated in other SYN+ACK packets it will be dropped anyway. So, it can't be used to birthday paradox attacks. But it can be used to carry out DoS attacks. Attack scenario: A is machine with mail service on port 25, running kernel 2.2 B is machine which is trying to send mail to machine A. Attacker is trying to prevent machine B from sending mail to machine A. If attacker will be able to predict the source port which machine B will use to connect to machine's A mail service, he can set up a 'trap' by sending SYN packet(s) to machine A port 25 with spoofed source host address and port number of machine B. Predicting source port number isn't hard in many environments as it is mostly a number from fixed range of well-known ports. The impact is much greater in applications that are connecting from particular (e.g. priviledged) source ports. I'm currently in the middle of developing convenient exploit for this vulnerability. It's working well in my laboratory but I will need to make it more robust so it will be possible to check for that vulnerabilty in production servers. I want to check more services and more environments to assure that my exploit will work well in different enviroments. For now, you can very easilly reconstruct this kernel behavior with 'hping': hping 10.20.20.20 -p 80 -s 20000 -a 10.10.10.10 -S -c 1 [do it few times] 10.20.20.20:~# netstat -an|grep 10.10.10.10 tcp 0 0 10.20.20.20:80 10.10.10.10:20000 SYN_RECV tcp 0 0 10.20.20.20:80 10.10.10.10:20000 SYN_RECV tcp 0 0 10.20.20.20:80 10.10.10.10:20000 SYN_RECV tcp 0 0 10.20.20.20:80 10.10.10.10:20000 SYN_RECV I think that the patch is very easy, althought I'm not kernel developer and I'm not even trying to make one myself. Could you tell me when you will be able to provide a patch? Of course I will not let the exploit leak out until you will provide fully tested patch. If you have any questions or comments regarding this bug, do not hesitate to contact me. Best regards, -- Tomasz Grabowski Technical University of Szczecin, +48 (91)4494234 Academic Centre of Computer Science www.man.szczecin.pl From olof@austin.ibm.com Mon Jan 12 12:49:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 12:49:21 -0800 (PST) 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.9) with SMTP id i0CKn26H032557 for ; Mon, 12 Jan 2004 12:49:02 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0CKmt19523008; Mon, 12 Jan 2004 15:48:55 -0500 Received: from austin.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0CKmqVo083706; Mon, 12 Jan 2004 13:48:54 -0700 Received: from austin.ibm.com (olof@olof.austin.ibm.com [9.53.85.118]) by austin.ibm.com (8.12.10/8.12.10) with ESMTP id i0CKmq8t037178; Mon, 12 Jan 2004 14:48:52 -0600 Message-ID: <400307ED.3060900@austin.ibm.com> Date: Mon, 12 Jan 2004 14:47:41 -0600 From: Olof Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031221 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Feldman, Scott" CC: netdev@oss.sgi.com, cramerj , milliner@us.ibm.com Subject: Re: [2.4] e1000 leaking pci mappings on rx errors? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2364 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olof@austin.ibm.com Precedence: bulk X-list: netdev Content-Length: 1214 Lines: 36 Feldman, Scott wrote: >>We have a machine here (running a RHEL 2.4.21-based kernel), >>that started showing leakage of PCI mappings when the driver >>was upgraded from 5.1.11 to 5.2.20. > > > Olof, please try 5.1.13 and 5.2.16 from sf.net/projects/e1000 to help > narrow the diff. I'm not seeing anything obvious in the diff between > 5.1.11 and 5.2.20 that would explain this. Scott, 5.1.13 is OK, 5.2.16 is leaking. Also, I noticed it's leaking quite fast, and even before any RX errors are shown. So my previous guess w.r.t. cause and effect might have been wrong: [root@primerib linux-2.4.21-6.EL-olof]# netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth1 1500 0 54793 0 0 0 67048 0 0 0 BMRU ~6240 PCI mappings had been allocated with the above statistics (eth1 is the problematic interface in our case). -Olof -- Olof Johansson Office: 4F005/905 pSeries Linux Development IBM Systems Group Email: olof@austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM From shemminger@osdl.org Mon Jan 12 13:46:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 13:47:13 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CLkw6H003872 for ; Mon, 12 Jan 2004 13:46:58 -0800 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 i0CLkjo05067; Mon, 12 Jan 2004 13:46:45 -0800 Date: Mon, 12 Jan 2004 13:46:45 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: [PATCH] bridge use read_lock when scanning device list Message-Id: <20040112134645.461f125e.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (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: 2365 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 Content-Length: 596 Lines: 22 On 2.6.1, bridge is using rtnl_shlock which is equivalent to rtnl_lock when all it really needs to do is read_lock(&dev_base_lock). diff -Nru a/net/bridge/br_if.c b/net/bridge/br_if.c --- a/net/bridge/br_if.c Mon Jan 12 13:45:44 2004 +++ b/net/bridge/br_if.c Mon Jan 12 13:45:44 2004 @@ -252,12 +252,12 @@ struct net_device *dev; int i = 0; - rtnl_shlock(); + read_lock(&dev_base_lock); for (dev = dev_base; dev && i < num; dev = dev->next) { if (dev->priv_flags & IFF_EBRIDGE) indices[i++] = dev->ifindex; } - rtnl_shunlock(); + read_unlock(&dev_base_lock); return i; } From shemminger@osdl.org Mon Jan 12 13:50:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 13:50:59 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CLoj6H004480 for ; Mon, 12 Jan 2004 13:50:46 -0800 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 i0CLoYo06250; Mon, 12 Jan 2004 13:50:34 -0800 Date: Mon, 12 Jan 2004 13:50:33 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] convert /proc/net/dev_mcast to seq_file Message-Id: <20040112135033.3b08f0e9.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (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: 2366 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 Content-Length: 3112 Lines: 132 Convert /proc/net/dev_mcast for 2.6 so it will work with large number of interfaces. diff -Nru a/net/core/dev_mcast.c b/net/core/dev_mcast.c --- a/net/core/dev_mcast.c Mon Jan 12 13:51:34 2004 +++ b/net/core/dev_mcast.c Mon Jan 12 13:51:34 2004 @@ -41,6 +41,7 @@ #include #include #include +#include #include #include #include @@ -219,59 +220,78 @@ } #ifdef CONFIG_PROC_FS -static int dev_mc_read_proc(char *buffer, char **start, off_t offset, - int length, int *eof, void *data) +static void *dev_mc_seq_start(struct seq_file *seq, loff_t *pos) { - off_t pos = 0, begin = 0; - struct dev_mc_list *m; - int len = 0; struct net_device *dev; + loff_t off = 0; read_lock(&dev_base_lock); for (dev = dev_base; dev; dev = dev->next) { - spin_lock_bh(&dev->xmit_lock); - for (m = dev->mc_list; m; m = m->next) { - int i; - - len += sprintf(buffer+len,"%-4d %-15s %-5d %-5d ", dev->ifindex, - dev->name, m->dmi_users, m->dmi_gusers); - - for (i = 0; i < m->dmi_addrlen; i++) - len += sprintf(buffer+len, "%02x", m->dmi_addr[i]); - - len += sprintf(buffer+len, "\n"); - - pos = begin + len; - if (pos < offset) { - len = 0; - begin = pos; - } - if (pos > offset + length) { - spin_unlock_bh(&dev->xmit_lock); - goto done; - } - } - spin_unlock_bh(&dev->xmit_lock); + if (off++ == *pos) + return dev; } - *eof = 1; + return NULL; +} -done: +static void *dev_mc_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + struct net_device *dev = v; + ++*pos; + return dev->next; +} + +static void dev_mc_seq_stop(struct seq_file *seq, void *v) +{ read_unlock(&dev_base_lock); - *start = buffer + (offset - begin); - len -= (offset - begin); - if (len > length) - len = length; - if (len < 0) - len = 0; - return len; } + + +static int dev_mc_seq_show(struct seq_file *seq, void *v) +{ + struct dev_mc_list *m; + struct net_device *dev = v; + + spin_lock_bh(&dev->xmit_lock); + for (m = dev->mc_list; m; m = m->next) { + int i; + + seq_printf(seq, "%-4d %-15s %-5d %-5d ", dev->ifindex, + dev->name, m->dmi_users, m->dmi_gusers); + + for (i = 0; i < m->dmi_addrlen; i++) + seq_printf(seq, "%02x", m->dmi_addr[i]); + + seq_putc(seq, '\n'); + } + spin_unlock_bh(&dev->xmit_lock); + return 0; +} + +static struct seq_operations dev_mc_seq_ops = { + .start = dev_mc_seq_start, + .next = dev_mc_seq_next, + .stop = dev_mc_seq_stop, + .show = dev_mc_seq_show, +}; + +static int dev_mc_seq_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &dev_mc_seq_ops); +} + +static struct file_operations dev_mc_seq_fops = { + .owner = THIS_MODULE, + .open = dev_mc_seq_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; + #endif void __init dev_mcast_init(void) { -#ifdef CONFIG_PROC_FS - create_proc_read_entry("net/dev_mcast", 0, 0, dev_mc_read_proc, NULL); -#endif + proc_net_fops_create("dev_mcast", 0, &dev_mc_seq_fops); } EXPORT_SYMBOL(dev_mc_add); From romieu@fr.zoreil.com Mon Jan 12 14:12:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 14:12:55 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CMCX6H005429 for ; Mon, 12 Jan 2004 14:12:34 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0CMC5sW007987; Mon, 12 Jan 2004 23:12:05 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0CMC47E007986; Mon, 12 Jan 2004 23:12:04 +0100 Date: Mon, 12 Jan 2004 23:12:04 +0100 From: Francois Romieu To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Subject: [patch] 2.6.1-bk1-netdev2 - Realtek 8169 braindamaged Message-ID: <20040112231204.B5983@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 2367 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 741 Lines: 26 Hi, please apply. $@!#&%{ bug in the r8169 driver. drivers/net/r8169.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/r8169.c~r8169-dma-api-rx-buffers-argl drivers/net/r8169.c --- linux-2.6.1-bk1-netdev2/drivers/net/r8169.c~r8169-dma-api-rx-buffers-argl 2004-01-12 23:01:59.000000000 +0100 +++ linux-2.6.1-bk1-netdev2-fr/drivers/net/r8169.c 2004-01-12 23:01:59.000000000 +0100 @@ -1408,7 +1408,7 @@ rtl8169_rx_interrupt(struct net_device * assert(tp != NULL); assert(ioaddr != NULL); - cur_rx = tp->cur_rx % RX_BUF_SIZE; + cur_rx = tp->cur_rx % NUM_RX_DESC; while (!(le32_to_cpu(tp->RxDescArray[cur_rx].status) & OWNbit)) { u32 status = le32_to_cpu(tp->RxDescArray[cur_rx].status); _ From jgarzik@pobox.com Mon Jan 12 14:21:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 14:21:20 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CML66H005968 for ; Mon, 12 Jan 2004 14:21:07 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:35728 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AgAQe-0006Qi-7N; Mon, 12 Jan 2004 22:21:00 +0000 Message-ID: <40031DBF.1050305@pobox.com> Date: Mon, 12 Jan 2004 17:20:47 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com Subject: Re: [patch] 2.6.1-bk1-netdev2 - Realtek 8169 braindamaged References: <20040112231204.B5983@electric-eye.fr.zoreil.com> In-Reply-To: <20040112231204.B5983@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2368 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 Content-Length: 21 Lines: 3 thanks, applied :) From jgarzik@pobox.com Mon Jan 12 14:22:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 14:22:54 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CMMe6H006344 for ; Mon, 12 Jan 2004 14:22:41 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:35731 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AgASF-0006Ra-Od; Mon, 12 Jan 2004 22:22:39 +0000 Message-ID: <40031E24.6040702@pobox.com> Date: Mon, 12 Jan 2004 17:22:28 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [NETDEV] experimental net driver queue updated References: <4000C5A3.5070101@pobox.com> <20040111004540.403ca854.akpm@osdl.org> In-Reply-To: <20040111004540.403ca854.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2369 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 Content-Length: 18 Lines: 3 thanks, applied From romieu@fr.zoreil.com Mon Jan 12 15:04:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 15:05:10 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CN4t6H007629 for ; Mon, 12 Jan 2004 15:04:56 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0CN3xsW008852; Tue, 13 Jan 2004 00:03:59 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0CN3v7v008851; Tue, 13 Jan 2004 00:03:57 +0100 Date: Tue, 13 Jan 2004 00:03:57 +0100 From: Francois Romieu To: netdev@oss.sgi.com Cc: dpollock@acm.org, damouse@ntlworld.com, brad@mainstreetsoftworks.com, kinetik@orcon.net.nz Subject: Re: Realtek 8169 Lock-ups Message-ID: <20040113000357.D5983@electric-eye.fr.zoreil.com> References: <1073507006.5151.61.camel@localhost> <20040107232034.A22930@electric-eye.fr.zoreil.com> <1073596694.6378.6.camel@localhost> <4001080D.3090401@pobox.com> <20040111124957.A18068@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040111124957.A18068@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Sun, Jan 11, 2004 at 12:49:57PM +0100 X-Organisation: Land of Sunshine Inc. X-archive-position: 2370 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 592 Lines: 24 Re, latest pile of r8169 related patches against 2.6.1-bk1 available at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.1-bk1 If you want to help: apply r8169-dma-api-tx.patch apply r8169-dma-api-rx-buffers.patch apply r8169-dma-api-rx-buffers-ahum.patch apply r8169-dma-api-rx-buffers-argl.patch <-- bug removed, sing and rejoice ! apply r8169-rx-fill-typo.patch apply r8169-start-xmit-fixes.patch apply r8169-dma-api-tx-buffers.patch apply r8169-rx_copybreak.patch -> does it work here ? apply r8169-mac-phy-version.patch apply r8169-buggy-devinitdata.patch -> and here ? -- Ueimor From scott.feldman@intel.com Mon Jan 12 15:36:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 15:37:03 -0800 (PST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CNao6H009686 for ; Mon, 12 Jan 2004 15:36:50 -0800 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0CNcoBX031145; Mon, 12 Jan 2004 23:38:51 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0CNYF0t025325; Mon, 12 Jan 2004 23:34:15 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011215363512497 ; Mon, 12 Jan 2004 15:36:35 -0800 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 12 Jan 2004 15:36:35 -0800 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: [2.4] e1000 leaking pci mappings on rx errors? Date: Mon, 12 Jan 2004 15:36:32 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [2.4] e1000 leaking pci mappings on rx errors? Thread-Index: AcPZTX7knqriL1FqQTWkkL94kRWzsAAFxEYg From: "Feldman, Scott" To: "Olof Johansson" Cc: , "cramerj" , X-OriginalArrivalTime: 12 Jan 2004 23:36:35.0171 (UTC) FILETIME=[EA8F1B30:01C3D964] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0CNao6H009686 X-archive-position: 2371 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 Content-Length: 975 Lines: 25 > Also, I noticed it's leaking quite fast, and even before any > RX errors are shown. So my previous guess w.r.t. cause and effect might > have been wrong: Ok, most of the changes to the driver are on the Tx side. Add this to 5.2.20 and let's see if we're hitting this path. Maybe there is still something wrong with the Tx unwind case where we run out of resources: diff -Nuarp e1000-5.2.20/src/e1000_main.c e1000-5.2.20-mod/src/e1000_main.c --- e1000-5.2.20/src/e1000_main.c 2003-09-30 23:22:19.000000000 -0700 +++ e1000-5.2.20-mod/src/e1000_main.c 2004-01-12 16:09:06.000000000 -0800 @@ -1837,6 +1837,8 @@ e1000_xmit_frame(struct sk_buff *skb, st if((count = e1000_tx_map(adapter, skb, first))) e1000_tx_queue(adapter, count, tx_flags); else { + static int stops = 0; + printk(KERN_ERR "stopping queue %d\n", ++stops); netif_stop_queue(netdev); return 1; } From jt@bougret.hpl.hp.com Mon Jan 12 16:12:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 16:13:16 -0800 (PST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D0Ci6H012392 for ; Mon, 12 Jan 2004 16:12:44 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel10.hp.com (Postfix) with ESMTP id 849791C036A5; Mon, 12 Jan 2004 15:43:33 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id PAA15457; Mon, 12 Jan 2004 15:43:33 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1AgBiX-0000Uj-00; Mon, 12 Jan 2004 15:43:33 -0800 Date: Mon, 12 Jan 2004 15:43:32 -0800 To: Jeff Garzik , "David S. Miller" , netdev@oss.sgi.com, Linux kernel mailing list Subject: [PATCH 2.6.X] SIOCSIFNAME wilcard support Message-ID: <20040112234332.GA1785@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: 2372 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 Content-Length: 2907 Lines: 86 Hi Jeff & Dave, The trivial patch below implement SIOCSIFNAME wilcard support. With the appropriate version of nameif (please ask me), you can do binding of this kind : ------------------------------------------------ # AMD Lance cards (pcnet32) amd* 00:10:83:* # Intersil PrismGT cards (prism54) wlan* 00:04:E2:* ------------------------------------------------ Of course, this make sense mostly for wireless cards. There is currently lot's od debate about the use of 'ethX' and 'wlanX' names for wireless driver, and some confusion resulting from that. Each driver use a different naming style, and some have module parameters to change the name prefix. Therefore, I think most distro and driver authors would benefit from such a feature. It would also enable to emulate the naming conventions of *BSD, but I don't know if I should list that as an argument ;-) I've run this patch for a while without any adverse effect. Please forward upstream ;-) Jean P.S. : Don't miss the second part of the change, we absolutely need to return the new name to user space. ------------------------------------------------------------- diff -u -p linux/net/core/dev.j1.c linux/net/core/dev.c --- linux/net/core/dev.j1.c Wed Dec 3 18:39:09 2003 +++ linux/net/core/dev.c Wed Dec 3 18:54:36 2003 @@ -2344,15 +2344,29 @@ static int dev_ifsioc(struct ifreq *ifr, if (dev->flags & IFF_UP) return -EBUSY; ifr->ifr_newname[IFNAMSIZ-1] = '\0'; - if (__dev_get_by_name(ifr->ifr_newname)) - return -EEXIST; - err = class_device_rename(&dev->class_dev, - ifr->ifr_newname); - if (!err) { + /* Check if name contains a wildcard */ + if (strchr(ifr->ifr_newname, '%')) { + int ret; + /* Find a free name based on format. + * dev_alloc_name() replaces "%d" with at max + * 2 digits, so no name overflow. - Jean II */ + ret = dev_alloc_name(dev, ifr->ifr_newname); + if (ret < 0) + return ret; + /* Copy the new name back to caller. */ + strncpy(ifr->ifr_newname, dev->name, IFNAMSIZ); + } else { + if (__dev_get_by_name(ifr->ifr_newname)) + return -EEXIST; strlcpy(dev->name, ifr->ifr_newname, IFNAMSIZ); - + } + err = class_device_rename(&dev->class_dev, dev->name); + if (!err) { notifier_call_chain(&netdev_chain, NETDEV_CHANGENAME, dev); + } else { + /* Restore original name */ + strlcpy(dev->name, ifr->ifr_name, IFNAMSIZ); } return err; @@ -2485,6 +2499,7 @@ int dev_ioctl(unsigned int cmd, void *ar * - require strict serialization. * - return a value */ + case SIOCSIFNAME: case SIOCGMIIPHY: case SIOCGMIIREG: if (!capable(CAP_NET_ADMIN)) @@ -2518,7 +2533,6 @@ int dev_ioctl(unsigned int cmd, void *ar case SIOCDELMULTI: case SIOCSIFHWBROADCAST: case SIOCSIFTXQLEN: - case SIOCSIFNAME: case SIOCSMIIREG: case SIOCBONDENSLAVE: case SIOCBONDRELEASE: From olof@austin.ibm.com Mon Jan 12 16:36:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 16:37:11 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D0av6H017271 for ; Mon, 12 Jan 2004 16:36:58 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0D0ap6t366764; Mon, 12 Jan 2004 19:36:51 -0500 Received: from austin.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0D0amo4136084; Mon, 12 Jan 2004 17:36:50 -0700 Received: from austin.ibm.com (olof@olof.austin.ibm.com [9.53.85.118]) by austin.ibm.com (8.12.10/8.12.10) with ESMTP id i0D0am8t035790; Mon, 12 Jan 2004 18:36:48 -0600 Message-ID: <40033D58.1080604@austin.ibm.com> Date: Mon, 12 Jan 2004 18:35:36 -0600 From: Olof Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031221 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Feldman, Scott" CC: netdev@oss.sgi.com, cramerj , milliner@us.ibm.com Subject: Re: [2.4] e1000 leaking pci mappings on rx errors? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2373 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olof@austin.ibm.com Precedence: bulk X-list: netdev Content-Length: 853 Lines: 20 Feldman, Scott wrote: > Ok, most of the changes to the driver are on the Tx side. Add this to > 5.2.20 and let's see if we're hitting this path. Maybe there is still > something wrong with the Tx unwind case where we run out of resources: It looks like I temporarily lost the machine, but I could give it one run before it happened. It was bursting huge number of those messages, but I had no chance to correlate them to the number of mappings that were leaked, since the machine pretty much locked up (serial console + too much kernel printks = very very slow machine). -Olof -- Olof Johansson Office: 4F005/905 pSeries Linux Development IBM Systems Group Email: olof@austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM From olof@austin.ibm.com Mon Jan 12 17:02:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 17:03:16 -0800 (PST) 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.9) with SMTP id i0D12v6H018739 for ; Mon, 12 Jan 2004 17:02:57 -0800 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0D12m19237862; Mon, 12 Jan 2004 20:02:49 -0500 Received: from austin.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0D12lK7026744; Mon, 12 Jan 2004 18:02:48 -0700 Received: from austin.ibm.com (olof@olof.austin.ibm.com [9.53.85.118]) by austin.ibm.com (8.12.10/8.12.10) with ESMTP id i0D12k8t030632; Mon, 12 Jan 2004 19:02:46 -0600 Message-ID: <4003436D.5000502@austin.ibm.com> Date: Mon, 12 Jan 2004 19:01:33 -0600 From: Olof Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031221 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Olof Johansson CC: "Feldman, Scott" , netdev@oss.sgi.com, cramerj , milliner@us.ibm.com Subject: Re: [2.4] e1000 leaking pci mappings on rx errors? References: <40033D58.1080604@austin.ibm.com> In-Reply-To: <40033D58.1080604@austin.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2374 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olof@austin.ibm.com Precedence: bulk X-list: netdev Content-Length: 1230 Lines: 30 Olof Johansson wrote: > Feldman, Scott wrote: > >> Ok, most of the changes to the driver are on the Tx side. Add this to >> 5.2.20 and let's see if we're hitting this path. Maybe there is still >> something wrong with the Tx unwind case where we run out of resources: > > > It looks like I temporarily lost the machine, but I could give it one > run before it happened. It was bursting huge number of those messages, > but I had no chance to correlate them to the number of mappings that > were leaked, since the machine pretty much locked up (serial console + > too much kernel printks = very very slow machine). I got it back quicker than I thought. :) It seems that after about 150k 'queue stopped' events we hit the case where it's leaked up to 1k pci mappings. The queue stopped messages start arriving as soon as the network load goes up. That's about the same point that the first rx errors show up too, in small numbers (<50 total). -Olof -- Olof Johansson Office: 4F005/905 pSeries Linux Development IBM Systems Group Email: olof@austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM From scott.feldman@intel.com Mon Jan 12 17:44:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 17:44:41 -0800 (PST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D1iR6H020438 for ; Mon, 12 Jan 2004 17:44:27 -0800 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0D1kRBX022581; Tue, 13 Jan 2004 01:46:27 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0D1hqfL021148; Tue, 13 Jan 2004 01:44:57 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011217441506844 ; Mon, 12 Jan 2004 17:44:15 -0800 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 12 Jan 2004 17:44:15 -0800 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: [Bonding-devel] Re: [bonding] Add basic support for dynamic configuration of bond interfaces Date: Mon, 12 Jan 2004 17:44:14 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Bonding-devel] Re: [bonding] Add basic support for dynamic configuration of bond interfaces Thread-Index: AcPX404QUetz7P+aRTSt4rJm9QEu6gBkPkYQ From: "Feldman, Scott" To: "Jeff Garzik" , "Noam, Amir" Cc: "Jay Vosburgh" , , X-OriginalArrivalTime: 13 Jan 2004 01:44:15.0722 (UTC) FILETIME=[C09A6CA0:01C3D976] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0D1iR6H020438 X-archive-position: 2375 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 > I don't disagree with the overall goal of these patches, but > I think we might need to pause a bit, and consider how best to > configure, add, and remove bonding interfaces, if we are coming > up with a new interface. Could sysfs be used for the bonding UI? Seems like a natural fit. Something like: 1) load bonding.o /sys/class/net/ eth0/ eth1/ add_bond << write-only file added 2) Create a bond: # echo "some params" >/sys/class/net/add_bond /sys/class/net/ eth0/ eth1/ bond0/ del_bond add_if del_if add_bond 3) Hook up the bond: # echo "eth0" >/sys/class/net/bond0/add_if # echo "eth1" >/sys/class/net/bond0/add_if /sys/class/net/ eth0/ eth1/ bond0/ -->eth0/ -->eth1/ del_bond add_if del_if new_bond 4) Delete the bond: # echo "byebye" >/sys/class/net/bond0/del_bond Etc. The whole kobject API is so clean, this should be trivial to code up. Seems like VLAN and bridge modules could follow. -scott From jgarzik@pobox.com Mon Jan 12 17:58:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 17:59:12 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D1ww6H021106 for ; Mon, 12 Jan 2004 17:58:59 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:35857 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AgDpZ-0000FX-AS; Tue, 13 Jan 2004 01:58:57 +0000 Message-ID: <400350D5.2060707@pobox.com> Date: Mon, 12 Jan 2004 20:58:45 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton , Netdev Subject: netdev3 posted... Content-Type: multipart/mixed; boundary="------------040802030002030207090206" X-archive-position: 2376 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 This is a multi-part message in MIME format. --------------040802030002030207090206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit With a couple fixes (another bad one in r8169) and a couple little things. Changelog delta versus netdev2 attached. The ppp header removal was Paul M's idea, but I took it farther, so it still needs ack'ing from him (as ppp maintainer). Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev3.patch.bz2 Full changelog: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev3.log Broken-out patches: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/broken-out/ --------------040802030002030207090206 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="changelog.txt" ChangeSet@1.1510.3.6, 2004-01-12 19:41:02-05:00, ak@muc.de [PATCH] variable number of dummy devices Uses the new module_params that nobody else uses now. ChangeSet@1.1510.15.54, 2004-01-12 17:27:00-05:00, jgarzik@redhat.com Eliminate ancient and unused include/linux/{if_pppvar,ppp}.h. Well, unused except for one silly constant in isdn_ppp.c. ChangeSet@1.1510.6.21, 2004-01-12 17:21:23-05:00, akpm@osdl.org [PATCH] fix netpoll printk bug ChangeSet@1.1510.9.18, 2004-01-12 17:19:54-05:00, romieu@fr.zoreil.com [netdrvr r8169] fix rx counter masking bug ChangeSet@1.1510.15.53, 2004-01-11 01:19:14-05:00, viro@parcelfarce.linux.theplanet.co.uk Remove unused and invalid 'struct ppp' definition from if_pppvar.h. ChangeSet@1.1510.10.3, 2004-01-11 01:09:34-05:00, viro@parcelfarce.linux.theplanet.co.uk [netdrvr forcedeth] kfree -> free_netdev ChangeSet@1.1510.3.5, 2004-01-11 01:08:18-05:00, viro@parcelfarce.linux.theplanet.co.uk [NET] fix leak in sch_teql Also note the fact that we're calling functions that may block, while holding a local spinlock. --------------040802030002030207090206-- From jgarzik@pobox.com Mon Jan 12 18:34:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 18:34:34 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D2YK6H023603 for ; Mon, 12 Jan 2004 18:34:21 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:35906 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AgENm-0000ZT-Uo; Tue, 13 Jan 2004 02:34:19 +0000 Message-ID: <4003591E.5050906@pobox.com> Date: Mon, 12 Jan 2004 21:34:06 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Lunz CC: netdev@oss.sgi.com Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> <4001C72E.8030108@pobox.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2377 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 Jason Lunz wrote: > jgarzik@pobox.com said: > >>The key question is what is the best interface for userland to configure >>in-kernel information -that is unrelated to a specific interface-. >>ethtool ioctl space doesn't apply, because that's a per-interface API. > > > ethtool is just as bad as brctl or any of the others. From (userland) > ethtool.c: ethtool contains only per-interface operations. One should not stuff extra-interface operations onto an ioctl, IMO. > calling a spade a spade, and all that. I don't see how that's any better > than brctl. The per-interface only comes into it when you copy a dev > name into a struct ifreq, but that doesn't associate the fd with the > interface in any way. You could go ahead and issue another ioctl on the > same fd for a different interface. I make it no secret that I dislike ioctls in general, and would like to move away from dependence on ioctl (and procfs) magic... Ideally one should be able to maintain and coordinate the ABI of one's own driver, without always going through a central authority for some magic number. Linux is (should be) more dynamic than that. It's a hotplug, decentralized world :) Jeff From Matt_Domsch@dell.com Mon Jan 12 18:34:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 18:34:48 -0800 (PST) Received: from smtp3.us.dell.com (smtp3.us.dell.com [143.166.148.134]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D2YZ6H023620 for ; Mon, 12 Jan 2004 18:34:35 -0800 Received: from humbolt.us.dell.com (humbolt.us.dell.com [10.9.160.254]) by smtp3.us.dell.com (8.12.10/8.12.9) with ESMTP id i0D2Y7tM019645; Mon, 12 Jan 2004 20:34:07 -0600 Date: Mon, 12 Jan 2004 20:34:07 -0600 (CST) From: Matt Domsch X-X-Sender: mdomsch@humbolt.us.dell.com To: "Feldman, Scott" cc: Jeff Garzik , "Noam, Amir" , Jay Vosburgh , , Subject: RE: [Bonding-devel] Re: [bonding] Add basic support for dynamic configuration of bond interfaces In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by smtp3.us.dell.com id i0D2Y7tM019645 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0D2YZ6H023620 X-archive-position: 2378 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Matt_Domsch@dell.com Precedence: bulk X-list: netdev > Could sysfs be used for the bonding UI?  Seems like a natural fit. > Something like: > # echo "some params" >/sys/class/net/add_bond > # echo "byebye" >/sys/class/net/bond0/del_bond FWIW, this is exactly what we're doing with the efivars module to create and destroy EFI Variables now, and appears to be a sane approach. Thanks, Matt -- Matt Domsch Sr. Software Engineer, Lead Engineer Dell Linux Solutions www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From chas@cmf.nrl.navy.mil Mon Jan 12 21:04:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 21:04:19 -0800 (PST) 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.9) with SMTP id i0D5456H000859 for ; Mon, 12 Jan 2004 21:04:05 -0800 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 i0D53nRr019754; Tue, 13 Jan 2004 00:03:49 -0500 (EST) Message-Id: <200401130503.i0D53nRr019754@ginger.cmf.nrl.navy.mil> To: davem@redhat.com cc: netdev@oss.sgi.com, "Jorge Boncompte [DTI2]" Subject: [PATCH][ATM]: [nicstar] convert to new style pci module (by "Jorge Boncompte [DTI2]" ) Reply-To: chas3@users.sourceforge.net Date: Tue, 13 Jan 2004 00:03:50 -0500 From: chas williams (contractor) X-Spam-Score: () hits=0.5 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 2379 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 please apply to 2.4 --thanks # 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.1382 -> 1.1383 # drivers/atm/nicstar.c 1.12 -> 1.13 # drivers/atm/atmdev_init.c 1.5 -> 1.6 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/01/12 chas@relax.cmf.nrl.navy.mil 1.1383 # [ATM]: [nicstar] convert to new style pci module (by "Jorge Boncompte [DTI2]" ) # -------------------------------------------- # diff -Nru a/drivers/atm/atmdev_init.c b/drivers/atm/atmdev_init.c --- a/drivers/atm/atmdev_init.c Mon Jan 12 20:11:48 2004 +++ b/drivers/atm/atmdev_init.c Mon Jan 12 20:11:48 2004 @@ -10,9 +10,6 @@ #ifdef CONFIG_ATM_ZATM extern int zatm_detect(void); #endif -#ifdef CONFIG_ATM_NICSTAR -extern int nicstar_detect(void); -#endif #ifdef CONFIG_ATM_AMBASSADOR extern int amb_detect(void); #endif @@ -40,9 +37,6 @@ devs = 0; #ifdef CONFIG_ATM_ZATM devs += zatm_detect(); -#endif -#ifdef CONFIG_ATM_NICSTAR - devs += nicstar_detect(); #endif #ifdef CONFIG_ATM_AMBASSADOR devs += amb_detect(); diff -Nru a/drivers/atm/nicstar.c b/drivers/atm/nicstar.c --- a/drivers/atm/nicstar.c Mon Jan 12 20:11:48 2004 +++ b/drivers/atm/nicstar.c Mon Jan 12 20:11:48 2004 @@ -214,8 +214,8 @@ static u32 ns_read_sram(ns_dev *card, u32 sram_address); static void ns_write_sram(ns_dev *card, u32 sram_address, u32 *value, int count); -static int __init ns_init_card(int i, struct pci_dev *pcidev); -static void __init ns_init_card_error(ns_dev *card, int error); +static int __devinit ns_init_card(int i, struct pci_dev *pcidev); +static void __devinit ns_init_card_error(ns_dev *card, int error); static scq_info *get_scq(int size, u32 scd); static void free_scq(scq_info *scq, struct atm_vcc *vcc); static void push_rxbufs(ns_dev *card, u32 type, u32 handle1, u32 addr1, @@ -276,198 +276,152 @@ /* Functions*******************************************************************/ -#ifdef MODULE - -int __init init_module(void) +static int __devinit nicstar_init_one(struct pci_dev *pcidev, + const struct pci_device_id *ent) { - int i; - unsigned error = 0; /* Initialized to remove compile warning */ - struct pci_dev *pcidev; - - XPRINTK("nicstar: init_module() called.\n"); - if(!pci_present()) - { - printk("nicstar: no PCI subsystem found.\n"); - return -EIO; - } + static int index = -1; + unsigned int error; - for(i = 0; i < NS_MAX_CARDS; i++) - cards[i] = NULL; + index++; + cards[index] = NULL; - pcidev = NULL; - for(i = 0; i < NS_MAX_CARDS; i++) - { - if ((pcidev = pci_find_device(PCI_VENDOR_ID_IDT, - PCI_DEVICE_ID_IDT_IDT77201, - pcidev)) == NULL) - break; - - error = ns_init_card(i, pcidev); - if (error) - cards[i--] = NULL; /* Try to find another card but don't increment index */ + error = ns_init_card(index, pcidev); + if (error) { + cards[index--] = NULL; /* don't increment index */ + goto err_out; } - if (i == 0) - { - if (!error) - { - printk("nicstar: no cards found.\n"); - return -ENXIO; - } - else - return -EIO; - } - TXPRINTK("nicstar: TX debug enabled.\n"); - RXPRINTK("nicstar: RX debug enabled.\n"); - PRINTK("nicstar: General debug enabled.\n"); -#ifdef PHY_LOOPBACK - printk("nicstar: using PHY loopback.\n"); -#endif /* PHY_LOOPBACK */ - XPRINTK("nicstar: init_module() returned.\n"); - - init_timer(&ns_timer); - ns_timer.expires = jiffies + NS_POLL_PERIOD; - ns_timer.data = 0UL; - ns_timer.function = ns_poll; - add_timer(&ns_timer); return 0; +err_out: + return -ENODEV; } -void cleanup_module(void) +static void __devexit nicstar_remove_one(struct pci_dev *pcidev) { int i, j; - unsigned short pci_command; - ns_dev *card; + ns_dev *card = pci_get_drvdata(pcidev); struct sk_buff *hb; struct sk_buff *iovb; struct sk_buff *lb; struct sk_buff *sb; - XPRINTK("nicstar: cleanup_module() called.\n"); - - if (MOD_IN_USE) - printk("nicstar: module in use, remove delayed.\n"); + i = card->index; - del_timer(&ns_timer); - - for (i = 0; i < NS_MAX_CARDS; i++) - { - if (cards[i] == NULL) - continue; - - card = cards[i]; + if (cards[i] == NULL) + return; - if (card->atmdev->phy && card->atmdev->phy->stop) - card->atmdev->phy->stop(card->atmdev); + if (card->atmdev->phy && card->atmdev->phy->stop) + card->atmdev->phy->stop(card->atmdev); - /* Stop everything */ - writel(0x00000000, card->membase + CFG); + /* Stop everything */ + writel(0x00000000, card->membase + CFG); - /* De-register device */ - atm_dev_deregister(card->atmdev); + /* De-register device */ + atm_dev_deregister(card->atmdev); - /* Disable memory mapping and busmastering */ - if (pci_read_config_word(card->pcidev, PCI_COMMAND, &pci_command) != 0) - { - printk("nicstar%d: can't read PCI_COMMAND.\n", i); - } - pci_command &= ~(PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER); - if (pci_write_config_word(card->pcidev, PCI_COMMAND, pci_command) != 0) - { - printk("nicstar%d: can't write PCI_COMMAND.\n", i); - } - - /* Free up resources */ - j = 0; - PRINTK("nicstar%d: freeing %d huge buffers.\n", i, card->hbpool.count); - while ((hb = skb_dequeue(&card->hbpool.queue)) != NULL) - { - dev_kfree_skb_any(hb); - j++; - } - PRINTK("nicstar%d: %d huge buffers freed.\n", i, j); - j = 0; - PRINTK("nicstar%d: freeing %d iovec buffers.\n", i, card->iovpool.count); - while ((iovb = skb_dequeue(&card->iovpool.queue)) != NULL) - { - dev_kfree_skb_any(iovb); - j++; - } - PRINTK("nicstar%d: %d iovec buffers freed.\n", i, j); - while ((lb = skb_dequeue(&card->lbpool.queue)) != NULL) - dev_kfree_skb_any(lb); - while ((sb = skb_dequeue(&card->sbpool.queue)) != NULL) - dev_kfree_skb_any(sb); - free_scq(card->scq0, NULL); - for (j = 0; j < NS_FRSCD_NUM; j++) - { - if (card->scd2vc[j] != NULL) - free_scq(card->scd2vc[j]->scq, card->scd2vc[j]->tx_vcc); - } - kfree(card->rsq.org); - kfree(card->tsq.org); - free_irq(card->pcidev->irq, card); - iounmap((void *) card->membase); - kfree(card); - + /* Disable PCI device */ + pci_disable_device(pcidev); + + /* Free up resources */ + j = 0; + PRINTK("nicstar%d: freeing %d huge buffers.\n", i, card->hbpool.count); + while ((hb = skb_dequeue(&card->hbpool.queue)) != NULL) + { + dev_kfree_skb_any(hb); + j++; } - XPRINTK("nicstar: cleanup_module() returned.\n"); + PRINTK("nicstar%d: %d huge buffers freed.\n", i, j); + j = 0; + PRINTK("nicstar%d: freeing %d iovec buffers.\n", i, card->iovpool.count); + while ((iovb = skb_dequeue(&card->iovpool.queue)) != NULL) + { + dev_kfree_skb_any(iovb); + j++; + } + PRINTK("nicstar%d: %d iovec buffers freed.\n", i, j); + while ((lb = skb_dequeue(&card->lbpool.queue)) != NULL) + dev_kfree_skb_any(lb); + while ((sb = skb_dequeue(&card->sbpool.queue)) != NULL) + dev_kfree_skb_any(sb); + free_scq(card->scq0, NULL); + for (j = 0; j < NS_FRSCD_NUM; j++) + { + if (card->scd2vc[j] != NULL) + free_scq(card->scd2vc[j]->scq, card->scd2vc[j]->tx_vcc); + } + kfree(card->rsq.org); + kfree(card->tsq.org); + free_irq(card->pcidev->irq, card); + iounmap((void *) card->membase); + kfree(card); } -#else -int __init nicstar_detect(void) +static struct pci_device_id nicstar_pci_tbl[] __devinitdata = { - int i; - unsigned error = 0; /* Initialized to remove compile warning */ - struct pci_dev *pcidev; + {PCI_VENDOR_ID_IDT, PCI_DEVICE_ID_IDT_IDT77201, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, + {0,} /* terminate list */ +}; +MODULE_DEVICE_TABLE(pci, nicstar_pci_tbl); - if(!pci_present()) - { - printk("nicstar: no PCI subsystem found.\n"); - return -EIO; - } - for(i = 0; i < NS_MAX_CARDS; i++) - cards[i] = NULL; - pcidev = NULL; - for(i = 0; i < NS_MAX_CARDS; i++) - { - if ((pcidev = pci_find_device(PCI_VENDOR_ID_IDT, - PCI_DEVICE_ID_IDT_IDT77201, - pcidev)) == NULL) - break; +static struct pci_driver nicstar_driver = { + .name = "nicstar", + .id_table = nicstar_pci_tbl, + .probe = nicstar_init_one, + .remove = __devexit_p(nicstar_remove_one), +}; - error = ns_init_card(i, pcidev); - if (error) - cards[i--] = NULL; /* Try to find another card but don't increment index */ - } - if (i == 0 && error) - return -EIO; +static int __init nicstar_init(void) +{ + unsigned error = 0; /* Initialized to remove compile warning */ + + XPRINTK("nicstar: nicstar_init() called.\n"); + + error = pci_module_init(&nicstar_driver); + TXPRINTK("nicstar: TX debug enabled.\n"); RXPRINTK("nicstar: RX debug enabled.\n"); PRINTK("nicstar: General debug enabled.\n"); #ifdef PHY_LOOPBACK printk("nicstar: using PHY loopback.\n"); #endif /* PHY_LOOPBACK */ - XPRINTK("nicstar: init_module() returned.\n"); + XPRINTK("nicstar: nicstar_init() returned.\n"); - init_timer(&ns_timer); - ns_timer.expires = jiffies + NS_POLL_PERIOD; - ns_timer.data = 0UL; - ns_timer.function = ns_poll; - add_timer(&ns_timer); - return i; + if (!error) { + init_timer(&ns_timer); + ns_timer.expires = jiffies + NS_POLL_PERIOD; + ns_timer.data = 0UL; + ns_timer.function = ns_poll; + add_timer(&ns_timer); + } + + return error; } -#endif /* MODULE */ + +static void __exit nicstar_cleanup(void) +{ + XPRINTK("nicstar: nicstar_cleanup() called.\n"); + + if (MOD_IN_USE) + printk("nicstar: module in use, remove delayed.\n"); + + del_timer(&ns_timer); + + pci_unregister_driver(&nicstar_driver); + + XPRINTK("nicstar: nicstar_cleanup() returned.\n"); +} + static u32 ns_read_sram(ns_dev *card, u32 sram_address) @@ -509,11 +463,10 @@ } -static int __init ns_init_card(int i, struct pci_dev *pcidev) +static int __devinit ns_init_card(int i, struct pci_dev *pcidev) { int j; struct ns_dev *card = NULL; - unsigned short pci_command; unsigned char pci_latency; unsigned error; u32 data; @@ -542,6 +495,8 @@ spin_lock_init(&card->int_lock); spin_lock_init(&card->res_lock); + pci_set_drvdata(pcidev, card); + card->index = i; card->atmdev = NULL; card->pcidev = pcidev; @@ -556,21 +511,7 @@ } PRINTK("nicstar%d: membase at 0x%x.\n", i, card->membase); - if (pci_read_config_word(pcidev, PCI_COMMAND, &pci_command) != 0) - { - printk("nicstar%d: can't read PCI_COMMAND.\n", i); - error = 4; - ns_init_card_error(card, error); - return error; - } - pci_command |= (PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER); - if (pci_write_config_word(pcidev, PCI_COMMAND, pci_command) != 0) - { - printk("nicstar%d: can't write PCI_COMMAND.\n", i); - error = 5; - ns_init_card_error(card, error); - return error; - } + pci_set_master(pcidev); if (pci_read_config_byte(pcidev, PCI_LATENCY_TIMER, &pci_latency) != 0) { @@ -996,7 +937,7 @@ -static void __init ns_init_card_error(ns_dev *card, int error) +static void __devinit ns_init_card_error(ns_dev *card, int error) { if (error >= 17) { @@ -1045,6 +986,7 @@ } if (error >= 3) { + pci_disable_device(card->pcidev); kfree(card); } } @@ -3148,3 +3090,8 @@ spin_unlock_irqrestore(&card->res_lock, flags); return (unsigned char) data; } + + + +module_init(nicstar_init); +module_exit(nicstar_cleanup); From chas@cmf.nrl.navy.mil Mon Jan 12 21:05:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 21:05:31 -0800 (PST) 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.9) with SMTP id i0D55H6H001078 for ; Mon, 12 Jan 2004 21:05:18 -0800 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 i0D552Rr019768; Tue, 13 Jan 2004 00:05:02 -0500 (EST) Message-Id: <200401130505.i0D552Rr019768@ginger.cmf.nrl.navy.mil> To: davem@redhat.com cc: netdev@oss.sgi.com, "Jorge Boncompte [DTI2]" Subject: [PATCH][ATM]: [nicstar] convert to new style pci module (by "Jorge Boncompte [DTI2]" ) Reply-To: chas3@users.sourceforge.net Date: Tue, 13 Jan 2004 00:05:02 -0500 From: chas williams (contractor) X-Spam-Score: () hits=0.5 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 2380 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 please apply to 2.6 --thanks # 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.1492 -> 1.1493 # drivers/atm/nicstar.c 1.20 -> 1.21 # drivers/atm/atmdev_init.c 1.5 -> 1.6 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/01/12 chas@relax.cmf.nrl.navy.mil 1.1493 # [ATM]: [nicstar] convert to new style pci module (by "Jorge Boncompte [DTI2]" ) # -------------------------------------------- # diff -Nru a/drivers/atm/atmdev_init.c b/drivers/atm/atmdev_init.c --- a/drivers/atm/atmdev_init.c Mon Jan 12 23:54:09 2004 +++ b/drivers/atm/atmdev_init.c Mon Jan 12 23:54:09 2004 @@ -10,9 +10,6 @@ #ifdef CONFIG_ATM_ZATM extern int zatm_detect(void); #endif -#ifdef CONFIG_ATM_NICSTAR -extern int nicstar_detect(void); -#endif #ifdef CONFIG_ATM_AMBASSADOR extern int amb_detect(void); #endif @@ -40,9 +37,6 @@ devs = 0; #ifdef CONFIG_ATM_ZATM devs += zatm_detect(); -#endif -#ifdef CONFIG_ATM_NICSTAR - devs += nicstar_detect(); #endif #ifdef CONFIG_ATM_AMBASSADOR devs += amb_detect(); diff -Nru a/drivers/atm/nicstar.c b/drivers/atm/nicstar.c --- a/drivers/atm/nicstar.c Mon Jan 12 23:54:09 2004 +++ b/drivers/atm/nicstar.c Mon Jan 12 23:54:09 2004 @@ -214,8 +214,8 @@ static u32 ns_read_sram(ns_dev *card, u32 sram_address); static void ns_write_sram(ns_dev *card, u32 sram_address, u32 *value, int count); -static int __init ns_init_card(int i, struct pci_dev *pcidev); -static void __init ns_init_card_error(ns_dev *card, int error); +static int __devinit ns_init_card(int i, struct pci_dev *pcidev); +static void __devinit ns_init_card_error(ns_dev *card, int error); static scq_info *get_scq(int size, u32 scd); static void free_scq(scq_info *scq, struct atm_vcc *vcc); static void push_rxbufs(ns_dev *card, u32 type, u32 handle1, u32 addr1, @@ -276,136 +276,151 @@ /* Functions*******************************************************************/ -static int __init nicstar_module_init(void) +static int __devinit nicstar_init_one(struct pci_dev *pcidev, + const struct pci_device_id *ent) { - int i; - unsigned error = 0; /* Initialized to remove compile warning */ - struct pci_dev *pcidev; + static int index = -1; + unsigned int error; - XPRINTK("nicstar: nicstar_module_init() called.\n"); + index++; + cards[index] = NULL; - for(i = 0; i < NS_MAX_CARDS; i++) - cards[i] = NULL; - - pcidev = NULL; - for(i = 0; i < NS_MAX_CARDS; i++) - { - if ((pcidev = pci_find_device(PCI_VENDOR_ID_IDT, - PCI_DEVICE_ID_IDT_IDT77201, - pcidev)) == NULL) - break; - - error = ns_init_card(i, pcidev); - if (error) - cards[i--] = NULL; /* Try to find another card but don't increment index */ + error = ns_init_card(index, pcidev); + if (error) { + cards[index--] = NULL; /* don't increment index */ + goto err_out; } - if (i == 0) - { - if (!error) - { - printk("nicstar: no cards found.\n"); - return -ENXIO; - } - else - return -EIO; - } - TXPRINTK("nicstar: TX debug enabled.\n"); - RXPRINTK("nicstar: RX debug enabled.\n"); - PRINTK("nicstar: General debug enabled.\n"); -#ifdef PHY_LOOPBACK - printk("nicstar: using PHY loopback.\n"); -#endif /* PHY_LOOPBACK */ - XPRINTK("nicstar: nicstar_module_init() returned.\n"); - - init_timer(&ns_timer); - ns_timer.expires = jiffies + NS_POLL_PERIOD; - ns_timer.data = 0UL; - ns_timer.function = ns_poll; - add_timer(&ns_timer); return 0; +err_out: + return -ENODEV; } -static void __exit nicstar_module_exit(void) +static void __devexit nicstar_remove_one(struct pci_dev *pcidev) { int i, j; - unsigned short pci_command; - ns_dev *card; + ns_dev *card = pci_get_drvdata(pcidev); struct sk_buff *hb; struct sk_buff *iovb; struct sk_buff *lb; struct sk_buff *sb; - XPRINTK("nicstar: cleanup_module() called.\n"); + i = card->index; - del_timer(&ns_timer); + if (cards[i] == NULL) + return; - for (i = 0; i < NS_MAX_CARDS; i++) + if (card->atmdev->phy && card->atmdev->phy->stop) + card->atmdev->phy->stop(card->atmdev); + + /* Stop everything */ + writel(0x00000000, card->membase + CFG); + + /* De-register device */ + atm_dev_deregister(card->atmdev); + + /* Disable PCI device */ + pci_disable_device(pcidev); + + /* Free up resources */ + j = 0; + PRINTK("nicstar%d: freeing %d huge buffers.\n", i, card->hbpool.count); + while ((hb = skb_dequeue(&card->hbpool.queue)) != NULL) { - if (cards[i] == NULL) - continue; + dev_kfree_skb_any(hb); + j++; + } + PRINTK("nicstar%d: %d huge buffers freed.\n", i, j); + j = 0; + PRINTK("nicstar%d: freeing %d iovec buffers.\n", i, card->iovpool.count); + while ((iovb = skb_dequeue(&card->iovpool.queue)) != NULL) + { + dev_kfree_skb_any(iovb); + j++; + } + PRINTK("nicstar%d: %d iovec buffers freed.\n", i, j); + while ((lb = skb_dequeue(&card->lbpool.queue)) != NULL) + dev_kfree_skb_any(lb); + while ((sb = skb_dequeue(&card->sbpool.queue)) != NULL) + dev_kfree_skb_any(sb); + free_scq(card->scq0, NULL); + for (j = 0; j < NS_FRSCD_NUM; j++) + { + if (card->scd2vc[j] != NULL) + free_scq(card->scd2vc[j]->scq, card->scd2vc[j]->tx_vcc); + } + kfree(card->rsq.org); + kfree(card->tsq.org); + free_irq(card->pcidev->irq, card); + iounmap((void *) card->membase); + kfree(card); +} - card = cards[i]; - if (card->atmdev->phy && card->atmdev->phy->stop) - card->atmdev->phy->stop(card->atmdev); - /* Stop everything */ - writel(0x00000000, card->membase + CFG); +static struct pci_device_id nicstar_pci_tbl[] __devinitdata = +{ + {PCI_VENDOR_ID_IDT, PCI_DEVICE_ID_IDT_IDT77201, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, + {0,} /* terminate list */ +}; +MODULE_DEVICE_TABLE(pci, nicstar_pci_tbl); - /* De-register device */ - atm_dev_deregister(card->atmdev); - /* Disable memory mapping and busmastering */ - if (pci_read_config_word(card->pcidev, PCI_COMMAND, &pci_command) != 0) - { - printk("nicstar%d: can't read PCI_COMMAND.\n", i); - } - pci_command &= ~(PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER); - if (pci_write_config_word(card->pcidev, PCI_COMMAND, pci_command) != 0) - { - printk("nicstar%d: can't write PCI_COMMAND.\n", i); - } - - /* Free up resources */ - j = 0; - PRINTK("nicstar%d: freeing %d huge buffers.\n", i, card->hbpool.count); - while ((hb = skb_dequeue(&card->hbpool.queue)) != NULL) - { - dev_kfree_skb_any(hb); - j++; - } - PRINTK("nicstar%d: %d huge buffers freed.\n", i, j); - j = 0; - PRINTK("nicstar%d: freeing %d iovec buffers.\n", i, card->iovpool.count); - while ((iovb = skb_dequeue(&card->iovpool.queue)) != NULL) - { - dev_kfree_skb_any(iovb); - j++; - } - PRINTK("nicstar%d: %d iovec buffers freed.\n", i, j); - while ((lb = skb_dequeue(&card->lbpool.queue)) != NULL) - dev_kfree_skb_any(lb); - while ((sb = skb_dequeue(&card->sbpool.queue)) != NULL) - dev_kfree_skb_any(sb); - free_scq(card->scq0, NULL); - for (j = 0; j < NS_FRSCD_NUM; j++) - { - if (card->scd2vc[j] != NULL) - free_scq(card->scd2vc[j]->scq, card->scd2vc[j]->tx_vcc); - } - kfree(card->rsq.org); - kfree(card->tsq.org); - free_irq(card->pcidev->irq, card); - iounmap((void *) card->membase); - kfree(card); - + +static struct pci_driver nicstar_driver = { + .name = "nicstar", + .id_table = nicstar_pci_tbl, + .probe = nicstar_init_one, + .remove = __devexit_p(nicstar_remove_one), +}; + + + +static int __init nicstar_init(void) +{ + unsigned error = 0; /* Initialized to remove compile warning */ + + XPRINTK("nicstar: nicstar_init() called.\n"); + + error = pci_module_init(&nicstar_driver); + + TXPRINTK("nicstar: TX debug enabled.\n"); + RXPRINTK("nicstar: RX debug enabled.\n"); + PRINTK("nicstar: General debug enabled.\n"); +#ifdef PHY_LOOPBACK + printk("nicstar: using PHY loopback.\n"); +#endif /* PHY_LOOPBACK */ + XPRINTK("nicstar: nicstar_init() returned.\n"); + + if (!error) { + init_timer(&ns_timer); + ns_timer.expires = jiffies + NS_POLL_PERIOD; + ns_timer.data = 0UL; + ns_timer.function = ns_poll; + add_timer(&ns_timer); } - XPRINTK("nicstar: cleanup_module() returned.\n"); + + return error; +} + + + +static void __exit nicstar_cleanup(void) +{ + XPRINTK("nicstar: nicstar_cleanup() called.\n"); + + del_timer(&ns_timer); + + pci_unregister_driver(&nicstar_driver); + + XPRINTK("nicstar: nicstar_cleanup() returned.\n"); } + + static u32 ns_read_sram(ns_dev *card, u32 sram_address) { unsigned long flags; @@ -445,11 +460,10 @@ } -static int __init ns_init_card(int i, struct pci_dev *pcidev) +static int __devinit ns_init_card(int i, struct pci_dev *pcidev) { int j; struct ns_dev *card = NULL; - unsigned short pci_command; unsigned char pci_latency; unsigned error; u32 data; @@ -478,6 +492,8 @@ spin_lock_init(&card->int_lock); spin_lock_init(&card->res_lock); + pci_set_drvdata(pcidev, card); + card->index = i; card->atmdev = NULL; card->pcidev = pcidev; @@ -492,21 +508,7 @@ } PRINTK("nicstar%d: membase at 0x%x.\n", i, card->membase); - if (pci_read_config_word(pcidev, PCI_COMMAND, &pci_command) != 0) - { - printk("nicstar%d: can't read PCI_COMMAND.\n", i); - error = 4; - ns_init_card_error(card, error); - return error; - } - pci_command |= (PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER); - if (pci_write_config_word(pcidev, PCI_COMMAND, pci_command) != 0) - { - printk("nicstar%d: can't write PCI_COMMAND.\n", i); - error = 5; - ns_init_card_error(card, error); - return error; - } + pci_set_master(pcidev); if (pci_read_config_byte(pcidev, PCI_LATENCY_TIMER, &pci_latency) != 0) { @@ -932,7 +934,7 @@ -static void __init ns_init_card_error(ns_dev *card, int error) +static void __devinit ns_init_card_error(ns_dev *card, int error) { if (error >= 17) { @@ -981,6 +983,7 @@ } if (error >= 3) { + pci_disable_device(card->pcidev); kfree(card); } } @@ -3099,5 +3102,7 @@ return (unsigned char) data; } -module_init(nicstar_module_init); -module_exit(nicstar_module_exit); + + +module_init(nicstar_init); +module_exit(nicstar_cleanup); From hibi665@oki.com Mon Jan 12 21:39:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 21:39:28 -0800 (PST) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D5dD6H002371 for ; Mon, 12 Jan 2004 21:39:14 -0800 Received: from aoi.okilab.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id OAA28837 for ; Tue, 13 Jan 2004 14:39:12 +0900 Received: (qmail 5505 invoked from network); 13 Jan 2004 14:39:11 +0900 Received: from dhcp23233.okilab.oki.co.jp (HELO kiso) (172.24.23.233) by aoi.okilab.oki.co.jp with SMTP; 13 Jan 2004 14:39:11 +0900 Message-Id: <20040113144059.728d0998%hibi665@oki.com> MIME-Version: 1.0 Date: Tue, 13 Jan 2004 14:40:59 +0900 X-Mailer: Denshin 8 Go V32.1.4.3 X-My-Real-Login-Name: thibi; aoi From: Takashi Hibi To: David Stevens Cc: netdev@oss.sgi.com, davem@redhat.com In-Reply-To: (Your message of "Mon, 12 Jan 2004 10:54:43 -0800") References: Subject: Re: MLD problems (again) [PATCH] X-archive-position: 2381 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hibi665@oki.com Precedence: bulk X-list: netdev David, The patch is very simple and I have no problem to apply it to 2.4 line kernel. I already applied this patch, but it didn't solve the problem. Regards, Takashi Hibi > > > > > Takashi, > The patch I sent was for 2.6.1, but it should also apply to > 2.4 line kernels and fix the problem. If you have problems getting > it to apply in 2.4, let me know what version and I can provide you > a patch specific for that kernel. > > +-DLS > > > Takashi Hibi on 01/12/2004 03:04:48 AM > > To: David Stevens/Beaverton/IBM@IBMUS > cc: netdev@oss.sgi.com, davem@redhat.com > Subject: Re: MLD problems (again) [PATCH] > > > > David, > > Thank you for the patch. > But at least it doesn't solve the problem for 2.4 line kernel. > I will also test with 2.6.1 later. > > Regards, > Takashi Hibi > >> >> >> >> >> Takashi, >> I believe the patch below will fix the problem you >> had with MCAST_JOIN_SOURCE_GROUP not sending a >> report. There was a typo in the source filter switching that did >> two deletes, rather than an delete and an add. >> >> Dave, >> Although IGMPv3 didn't have any problems, this patch >> also re-arranges the order of the filter changes. I think it's cleaner >> to add the new one first and then delete the old one, rather than >> having a small window with no filter set. So, this is a bug fix for MLD >> and a code clean-up for IGMPv3. >> This bug and patch should also apply to the 2.4 line. >> >> +-DLS >> >> [included in-line for viewing and as an attachment for unmangled >> whitespace] >> >> --- linux-2.6.1/net/ipv6/mcast.c 2004-01-08 22:59:56.000000000 -0800 >> +++ linux-2.6.1F1/net/ipv6/mcast.c 2004-01-11 21:06:05.000000000 -0800 >> @@ -372,9 +372,9 @@ >> goto done; >> } else if (pmc->sfmode != omode) { >> /* allow mode switches for empty-set filters */ >> + ip6_mc_add_src(idev, group, omode, 0, 0, 0); >> ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); >> pmc->sfmode = omode; >> - ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); >> } >> >> psl = pmc->sflist; >> --- linux-2.6.1/net/ipv4/igmp.c 2004-01-08 23:00:12.000000000 -0800 >> +++ linux-2.6.1F1/net/ipv4/igmp.c 2004-01-11 21:27:41.000000000 -0800 >> @@ -1749,11 +1749,10 @@ >> goto done; >> } else if (pmc->sfmode != omode) { >> /* allow mode switches for empty-set filters */ >> + ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, omode, 0, 0, 0); >> ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, >> 0, 0); >> pmc->sfmode = omode; >> - ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, >> - 0, 0); >> } >> >> psl = pmc->sflist; >> >> (See attached file: 2.6.1MLD.patch) > > > From hibi665@oki.com Mon Jan 12 23:57:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 23:58:16 -0800 (PST) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D7vs6H005829 for ; Mon, 12 Jan 2004 23:57:55 -0800 Received: from aoi.okilab.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id QAA17607 for ; Tue, 13 Jan 2004 16:57:53 +0900 Received: (qmail 18548 invoked from network); 13 Jan 2004 16:57:52 +0900 Received: from dhcp23233.okilab.oki.co.jp (HELO kiso) (172.24.23.233) by aoi.okilab.oki.co.jp with SMTP; 13 Jan 2004 16:57:52 +0900 Message-Id: <20040113165941.730c0345%hibi665@oki.com> MIME-Version: 1.0 Date: Tue, 13 Jan 2004 16:59:41 +0900 X-Mailer: Denshin 8 Go V32.1.4.3 X-My-Real-Login-Name: thibi; aoi From: Takashi Hibi To: David Stevens Cc: netdev@oss.sgi.com, davem@redhat.com In-Reply-To: (Your message of "Tue, 13 Jan 2004 14:40:59 +0900") <20040113144059.728d0998%hibi665@oki.com> References: <20040113144059.728d0998%hibi665@oki.com> Subject: Re: MLD problems (again) [PATCH] X-archive-position: 2382 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hibi665@oki.com Precedence: bulk X-list: netdev David, Good news. I found a mistake which I made when I built the kernel. After fixing it, the problem is solved and the Linux box can join multicast group at once. The patch is OK. Thank you. Takashi Hibi > David, > > The patch is very simple and I have no problem to apply it to 2.4 line kernel. > I already applied this patch, but it didn't solve the problem. > > Regards, > Takashi Hibi > >> >> >> >> >> Takashi, >> The patch I sent was for 2.6.1, but it should also apply to >> 2.4 line kernels and fix the problem. If you have problems getting >> it to apply in 2.4, let me know what version and I can provide you >> a patch specific for that kernel. >> >> +-DLS >> >> >> Takashi Hibi on 01/12/2004 03:04:48 AM >> >> To: David Stevens/Beaverton/IBM@IBMUS >> cc: netdev@oss.sgi.com, davem@redhat.com >> Subject: Re: MLD problems (again) [PATCH] >> >> >> >> David, >> >> Thank you for the patch. >> But at least it doesn't solve the problem for 2.4 line kernel. >> I will also test with 2.6.1 later. >> >> Regards, >> Takashi Hibi >> >>> >>> >>> >>> >>> Takashi, >>> I believe the patch below will fix the problem you >>> had with MCAST_JOIN_SOURCE_GROUP not sending a >>> report. There was a typo in the source filter switching that did >>> two deletes, rather than an delete and an add. >>> >>> Dave, >>> Although IGMPv3 didn't have any problems, this patch >>> also re-arranges the order of the filter changes. I think it's cleaner >>> to add the new one first and then delete the old one, rather than >>> having a small window with no filter set. So, this is a bug fix for MLD >>> and a code clean-up for IGMPv3. >>> This bug and patch should also apply to the 2.4 line. >>> >>> +-DLS >>> >>> [included in-line for viewing and as an attachment for unmangled >>> whitespace] >>> >>> --- linux-2.6.1/net/ipv6/mcast.c 2004-01-08 22:59:56.000000000 -0800 >>> +++ linux-2.6.1F1/net/ipv6/mcast.c 2004-01-11 21:06:05.000000000 -0800 >>> @@ -372,9 +372,9 @@ >>> goto done; >>> } else if (pmc->sfmode != omode) { >>> /* allow mode switches for empty-set filters */ >>> + ip6_mc_add_src(idev, group, omode, 0, 0, 0); >>> ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); >>> pmc->sfmode = omode; >>> - ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); >>> } >>> >>> psl = pmc->sflist; >>> --- linux-2.6.1/net/ipv4/igmp.c 2004-01-08 23:00:12.000000000 -0800 >>> +++ linux-2.6.1F1/net/ipv4/igmp.c 2004-01-11 21:27:41.000000000 -0800 >>> @@ -1749,11 +1749,10 @@ >>> goto done; >>> } else if (pmc->sfmode != omode) { >>> /* allow mode switches for empty-set filters */ >>> + ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, omode, 0, 0, 0); >>> ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, >>> 0, 0); >>> pmc->sfmode = omode; >>> - ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, >>> - 0, 0); >>> } >>> >>> psl = pmc->sflist; >>> >>> (See attached file: 2.6.1MLD.patch) >> >> From dlstevens@us.ibm.com Tue Jan 13 00:07:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 00:07:43 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D87P6H006461 for ; Tue, 13 Jan 2004 00:07:26 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0D87I6t302352; Tue, 13 Jan 2004 03:07:18 -0500 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0D87Hj4126158; Tue, 13 Jan 2004 01:07:17 -0700 Importance: Normal Sensitivity: Subject: Re: MLD problems (again) [PATCH] To: Takashi Hibi Cc: netdev@oss.sgi.com, davem@redhat.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Tue, 13 Jan 2004 01:07:13 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/13/2004 01:07:16 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE489DFBFA5018f9e8a93df938690918c07BBE489DFBFA501" Content-Disposition: inline X-archive-position: 2383 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev --0__=07BBE489DFBFA5018f9e8a93df938690918c07BBE489DFBFA501 Content-type: text/plain; charset=US-ASCII Takashi, Great! I actually built it for 2.4.24 myself and was about to ask for more information, since it worked for me. +-DLS Takashi Hibi on 01/12/2004 11:59:41 PM To: David Stevens/Beaverton/IBM@IBMUS cc: netdev@oss.sgi.com, davem@redhat.com Subject: Re: MLD problems (again) [PATCH] David, Good news. I found a mistake which I made when I built the kernel. After fixing it, the problem is solved and the Linux box can join multicast group at once. The patch is OK. Thank you. Takashi Hibi > David, > > The patch is very simple and I have no problem to apply it to 2.4 line kernel. > I already applied this patch, but it didn't solve the problem. > > Regards, > Takashi Hibi > >> >> >> >> >> Takashi, >> The patch I sent was for 2.6.1, but it should also apply to >> 2.4 line kernels and fix the problem. If you have problems getting >> it to apply in 2.4, let me know what version and I can provide you >> a patch specific for that kernel. >> >> +-DLS >> >> >> Takashi Hibi on 01/12/2004 03:04:48 AM >> >> To: David Stevens/Beaverton/IBM@IBMUS >> cc: netdev@oss.sgi.com, davem@redhat.com >> Subject: Re: MLD problems (again) [PATCH] >> >> >> >> David, >> >> Thank you for the patch. >> But at least it doesn't solve the problem for 2.4 line kernel. >> I will also test with 2.6.1 later. >> >> Regards, >> Takashi Hibi >> >>> >>> >>> >>> >>> Takashi, >>> I believe the patch below will fix the problem you >>> had with MCAST_JOIN_SOURCE_GROUP not sending a >>> report. There was a typo in the source filter switching that did >>> two deletes, rather than an delete and an add. >>> >>> Dave, >>> Although IGMPv3 didn't have any problems, this patch >>> also re-arranges the order of the filter changes. I think it's cleaner >>> to add the new one first and then delete the old one, rather than >>> having a small window with no filter set. So, this is a bug fix for MLD >>> and a code clean-up for IGMPv3. >>> This bug and patch should also apply to the 2.4 line. >>> >>> +-DLS >>> >>> [included in-line for viewing and as an attachment for unmangled >>> whitespace] >>> >>> --- linux-2.6.1/net/ipv6/mcast.c 2004-01-08 22:59:56.000000000 -0800 >>> +++ linux-2.6.1F1/net/ipv6/mcast.c 2004-01-11 21:06:05.000000000 -0800 >>> @@ -372,9 +372,9 @@ >>> goto done; >>> } else if (pmc->sfmode != omode) { >>> /* allow mode switches for empty-set filters */ >>> + ip6_mc_add_src(idev, group, omode, 0, 0, 0); >>> ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); >>> pmc->sfmode = omode; >>> - ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); >>> } >>> >>> psl = pmc->sflist; >>> --- linux-2.6.1/net/ipv4/igmp.c 2004-01-08 23:00:12.000000000 -0800 >>> +++ linux-2.6.1F1/net/ipv4/igmp.c 2004-01-11 21:27:41.000000000 -0800 >>> @@ -1749,11 +1749,10 @@ >>> goto done; >>> } else if (pmc->sfmode != omode) { >>> /* allow mode switches for empty-set filters */ >>> + ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, omode, 0, 0, 0); >>> ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, >>> 0, 0); >>> pmc->sfmode = omode; >>> - ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, >>> - 0, 0); >>> } >>> >>> psl = pmc->sflist; >>> >>> (See attached file: 2.6.1MLD.patch) >> >> --0__=07BBE489DFBFA5018f9e8a93df938690918c07BBE489DFBFA501 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Takashi,
Great! I actually built it for 2.4.24 myself and was about to ask for
more information, since it worked for me.

+-DLS

To: David Stevens/Beaverton/IBM@IBMUS
cc: netdev@oss.sgi.com, davem@redhat.com
Subject: Re: MLD problems (again) [PATCH]



David,

Good news.
I found a mistake which I made when I built the kernel.
After fixing it, the problem is solved and the Linux box can join
multicast group at once.
The patch is OK.

Thank you.

Takashi Hibi

> David,
>
> The patch is very simple and I have no problem to apply it to 2.4 line kernel.
> I already applied this patch, but it didn't solve the problem.
>
> Regards,
> Takashi Hibi
>
>>
>>
>>
>>
>> Takashi,
>>       The patch I sent was for 2.6.1, but it should also apply to
>> 2.4 line kernels and fix the problem. If you have problems getting
>> it to apply in 2.4, let me know what version and I can provide you
>> a patch specific for that kernel.
>>
>>                               +-DLS
>>
>>
>> Takashi Hibi <hibi665@oki.com> on 01/12/2004 03:04:48 AM
>>
>> To:    David Stevens/Beaverton/IBM@IBMUS
>> cc:    netdev@oss.sgi.com, davem@redhat.com
>> Subject:    Re: MLD problems (again) [PATCH]
>>
>>
>>
>> David,
>>
>> Thank you for the patch.
>> But at least it doesn't solve the problem for 2.4 line kernel.
>> I will also test with 2.6.1 later.
>>
>> Regards,
>> Takashi Hibi
>>
>>>
>>>
>>>
>>>
>>> Takashi,
>>>       I believe the patch below will fix the problem you
>>> had with MCAST_JOIN_SOURCE_GROUP not sending a
>>> report. There was a typo in the source filter switching that did
>>> two deletes, rather than an delete and an add.
>>>
>>> Dave,
>>>       Although IGMPv3 didn't have any problems, this patch
>>> also re-arranges the order of the filter changes. I think it's cleaner
>>> to add the new one first and then delete the old one, rather than
>>> having a small window with no filter set. So, this is a bug fix for MLD
>>> and a code clean-up for IGMPv3.
>>>       This bug and patch should also apply to the 2.4 line.
>>>
>>>                         +-DLS
>>>
>>> [included in-line for viewing and as an attachment for unmangled
>>>       whitespace]
>>>
>>> --- linux-2.6.1/net/ipv6/mcast.c    2004-01-08 22:59:56.000000000 -0800
>>> +++ linux-2.6.1F1/net/ipv6/mcast.c  2004-01-11 21:06:05.000000000 -0800
>>> @@ -372,9 +372,9 @@
>>>                   goto done;
>>>       } else if (pmc->sfmode != omode) {
>>>             /* allow mode switches for empty-set filters */
>>> +           ip6_mc_add_src(idev, group, omode, 0, 0, 0);
>>>             ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0);
>>>             pmc->sfmode = omode;
>>> -           ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0);
>>>       }
>>>
>>>       psl = pmc->sflist;
>>> --- linux-2.6.1/net/ipv4/igmp.c     2004-01-08 23:00:12.000000000 -0800
>>> +++ linux-2.6.1F1/net/ipv4/igmp.c   2004-01-11 21:27:41.000000000 -0800
>>> @@ -1749,11 +1749,10 @@
>>>                   goto done;
>>>       } else if (pmc->sfmode != omode) {
>>>             /* allow mode switches for empty-set filters */
>>> +           ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, omode, 0, 0, 0);
>>>             ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0,
>>>                   0, 0);
>>>             pmc->sfmode = omode;
>>> -           ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0,
>>> -                 0, 0);
>>>       }
>>>
>>>       psl = pmc->sflist;
>>>
>>> (See attached file: 2.6.1MLD.patch)
>>
>>


--0__=07BBE489DFBFA5018f9e8a93df938690918c07BBE489DFBFA501-- From hadi@cyberus.ca Tue Jan 13 04:29:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 04:29:43 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DCTT6H021020 for ; Tue, 13 Jan 2004 04:29:30 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1AgNfd-0001vv-Um; Tue, 13 Jan 2004 07:29:22 -0500 Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces From: jamal Reply-To: hadi@cyberus.ca To: Andi Kleen Cc: jgarzik@pobox.com, greearb@candelatech.com, amir.noam@intel.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <20040112160446.691e187e.ak@suse.de> References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> <4001C72E.8030108@pobox.com> <20040112133816.57993f44.ak@suse.de> <1073915461.1118.342.camel@jzny.localdomain> <20040112160446.691e187e.ak@suse.de> Content-Type: text/plain Organization: jamalopolis Message-Id: <1073996930.1039.247.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 13 Jan 2004 07:28:50 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2384 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 Mon, 2004-01-12 at 10:04, Andi Kleen wrote: [..] > When you use [su]64: > > make sure the data element is explicitely padded to be on a 8 byte boundary > in the structure. The reason is that alignof(u64) on i386 is 4 but 8 on ia64/x86-64 > and the structure layout could change. > > > also when you use 64bit types make sure the complete structure is padded to 8 bytes. > The x86-64 ABI pads any data structure to the alignof() of its biggest member > to get good alignment for arrays. This is what broke PF_KEY - it is missing this > padding and the structure layout ends up differently with nested structures. > The behavior of some 32 bit archs alignof()e.g ppc is similar in aligning to its biggest member. We have some major problems with include/linux/pkt_sched.h::tc_stats for example; i just have to keep hacking tc on ppc everytime so it doesnt stop processing and bitch about truncated stats; [this happens when doing a sizeof() of on-the-wire data passed from the kernel being compared against sizeof(tc_stats)]. I recall there are a few other similar structures. It didnt seem like there was a clean solution when i last looked at this. It seems we may need surgery on a few places like this and may require a few #ifdefs. Any thoughts on this particular one? cheers, jamal From ak@suse.de Tue Jan 13 04:39:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 04:40:00 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DCdk6H021679 for ; Tue, 13 Jan 2004 04:39:47 -0800 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 0013519DA65D; Tue, 13 Jan 2004 13:39:23 +0100 (CET) Received: by wotan.suse.de (Postfix, from userid 14000) id A10A3106DA; Tue, 13 Jan 2004 13:39:22 +0100 (CET) Date: Tue, 13 Jan 2004 13:39:22 +0100 From: Andi Kleen To: jamal Cc: Andi Kleen , jgarzik@pobox.com, greearb@candelatech.com, amir.noam@intel.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces Message-ID: <20040113123922.GC31630@wotan.suse.de> References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> <4001C72E.8030108@pobox.com> <20040112133816.57993f44.ak@suse.de> <1073915461.1118.342.camel@jzny.localdomain> <20040112160446.691e187e.ak@suse.de> <1073996930.1039.247.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1073996930.1039.247.camel@jzny.localdomain> X-archive-position: 2385 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 Tue, Jan 13, 2004 at 07:28:50AM -0500, jamal wrote: > The behavior of some 32 bit archs alignof()e.g ppc is similar in > aligning to its biggest member. > We have some major problems with include/linux/pkt_sched.h::tc_stats for > example; i just have to keep hacking tc on ppc everytime so it doesnt > stop processing and bitch about truncated stats; [this happens when > doing a sizeof() of on-the-wire data passed from the kernel being > compared against sizeof(tc_stats)]. I recall there are a few other > similar structures. It didnt seem like there was a clean solution when i > last looked at this. It seems we may need surgery on a few places like > this and may require a few #ifdefs. Any thoughts on this particular one? I don't think it can be fixed with #ifdefs. For existing structures we cannot change the layout because they are already enshrined in the ABI. You have to translate them in the emulation layer somehow or just give up. And for new ones just add all necessary padding explicitely or best avoid __u64 (which causes most problems) In fact we should have some watchdog enforcing these rules for all new kernel submissions . In fact DaveM did that for some time, but he unfortunately only enforced the rules needed for sparc64 which are a subset of those needed by other ports. -Andi From hadi@cyberus.ca Tue Jan 13 06:17:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 06:18:12 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DEHu6H025216 for ; Tue, 13 Jan 2004 06:17:56 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1AgPMe-000747-4c; Tue, 13 Jan 2004 09:17:52 -0500 Subject: RE: [Bonding-devel] Re: [bonding] Add basic support for dynamic configuration of bond interfaces From: jamal Reply-To: hadi@cyberus.ca To: Matt Domsch Cc: "Feldman, Scott" , Jeff Garzik , "Noam, Amir" , Jay Vosburgh , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: jamalopolis Message-Id: <1074003440.1037.429.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 13 Jan 2004 09:17:20 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2386 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 I think this would be fine if you have some simple policy maybe upto 5 variables. Its simplicty gives it a lot of value. However, once you start getting into more demanding setups with lotsa table based configs this is quickly going to turn into a configuration nightmare. What we should shoot for with netlink is to make it as stoopid-proof as well - although not too stoopid proof to be dangerous. cheers, jamal On Mon, 2004-01-12 at 21:34, Matt Domsch wrote: > > Could sysfs be used for the bonding UI? Seems like a natural fit. > > Something like: > > # echo "some params" >/sys/class/net/add_bond > > # echo "byebye" >/sys/class/net/bond0/del_bond > > FWIW, this is exactly what we're doing with the efivars module to create > and destroy EFI Variables now, and appears to be a sane approach. > > Thanks, > Matt From hadi@cyberus.ca Tue Jan 13 07:00:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 07:00:47 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DF0X6H026717 for ; Tue, 13 Jan 2004 07:00:33 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1AfkMs-0004RI-IL; Sun, 11 Jan 2004 13:31:22 -0500 Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces From: jamal Reply-To: hadi@cyberus.ca To: Amir Noam Cc: Jeff Garzik , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <200401111628.07930.amir.noam@intel.com> References: <200401111628.07930.amir.noam@intel.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1073845851.1115.297.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Jan 2004 13:30:51 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2387 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 Sun, 2004-01-11 at 09:28, Amir Noam wrote: > > > I would suggest a simple character device (misc_register), and let > > the userland application configure settings unrelated to a single > > object. > > I was trying to follow the example of several other network modules > (e.g. vlan, dlci, bridge) that use a socket level ioctl hook to > handle such deviceless commands. > > Do you think that a char device is preferrable, given that other > similar modules use a socket ioctl hook? I think a netlink interface would be the better alternative. The L2C netlink socket protocol would be appropriate for bonding at least for 2.6.x. Bridging, VLAN should also move to this. cheers, jamal From pollockd@magma.ca Tue Jan 13 08:56:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 09:17:24 -0800 (PST) Received: from mx2.magma.ca (mx2.magma.ca [206.191.0.250]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DGuJ6H004038 for ; Tue, 13 Jan 2004 08:56:19 -0800 Received: from mail2.magma.ca (mail2.magma.ca [206.191.0.214]) by mx2.magma.ca (Magma Relay Server) with ESMTP id i0DGteKv004897; Tue, 13 Jan 2004 11:55:40 -0500 Received: from 9.26.194.135 (ottawa2.oti.com [204.138.98.60]) (authenticated bits=0) by mail2.magma.ca (8.12.10/8.12.9) with ESMTP id i0DGtcsT008232 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 Jan 2004 11:55:40 -0500 Subject: Re: Realtek 8169 Lock-ups From: pollockd@magma.ca Reply-To: dpollock@acm.org To: Jeff Garzik Cc: Francois Romieu , netdev@oss.sgi.com, damouse@ntlworld.com, brad@mainstreetsoftworks.com, kinetik@orcon.net.nz In-Reply-To: <4001A41C.3070205@pobox.com> References: <200401111623.i0BGNg3O028990@webmail1.magma.ca> <4001A41C.3070205@pobox.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-AiLDoAMaC7ybRbg9RUED" Message-Id: <1074012941.5886.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 13 Jan 2004 11:55:41 -0500 X-archive-position: 2389 X-Approved-By: ralf@linux-mips.org X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pollockd@magma.ca Precedence: bulk X-list: netdev Content-Length: 1584 Lines: 57 --=-AiLDoAMaC7ybRbg9RUED Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2004-01-11 at 14:29, Jeff Garzik wrote: > Douglas Pollock wrote: > The kernel comes with "pktgen" which is a free packet generator you can=20 > use for stressing kernels and LANs. There is also ttcp, nttcp, various=20 > filesystems tests over NFS (such as bonnie++), various block device=20 > tests over nbd (network block device), ... Thanks for that. I should have remembered the packet generator. Using pktgen, I am able to reproduce the problem. HARDWARE: Intel P4 with hyper-threading enabled Realtek 8169 (rev. 10) Switched 100Mbps network A second machine on the same network (to receive test packets) SOFTWARE: Kernel 2.6.0 or 2.6.1-rc1 (possibly others), with SMP for 2 processors, Realtek 8169 driver, and packet generator STEPS TO REPRODUCE: 1.) Set up the ipg script to send to the second machine on the 8169 NIC. 2.) pgset pkt_size 9014 3.) pg OBSERVATIONS: Soon after step #3, the 8169 NIC will stop responding (note: the netdev watchdog reports a timeout in dmesg). No packets get through. However, everything else still works. Disabling SMP in the kernel fixes this problem. Doug. --=-AiLDoAMaC7ybRbg9RUED Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQBABCMLLhh1LVU8SusRAtTXAJoCQdN5E8uvmbm6LeDVBfZD6DJ/DwCgrIsb wWWlcJD8EzfThXM3bVUX3Kk= =fKX6 -----END PGP SIGNATURE----- --=-AiLDoAMaC7ybRbg9RUED-- From scott.feldman@intel.com Tue Jan 13 10:52:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 10:53:07 -0800 (PST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DIqq6H007521 for ; Tue, 13 Jan 2004 10:52:53 -0800 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: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0DInYOv004724; Tue, 13 Jan 2004 18:49:35 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0DIp2AG008926; Tue, 13 Jan 2004 18:51:29 GMT Received: from [134.134.3.50] ([134.134.3.50]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011310520832358 ; Tue, 13 Jan 2004 10:52:08 -0800 Date: Tue, 13 Jan 2004 11:28:38 -0800 (PST) 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: [e100 netdev-2.6 1/2] fix slab corruption 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: 2390 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 Content-Length: 10404 Lines: 346 * Addresses two problems, both resulting in slab corruption: 1) driver indicating skb while HW is still DMA'ing (ouch!), 2) driver not stopping receiver activity before downing i/f. Fix is 1) wait for RNR (receiver-no-resources) interrupt before restarting receiver, 2) reseting HW to stop receiver before stopping i/f. ---------- --- net-drivers-2.5-exp/drivers/net/e100.c.orig 2004-01-09 16:41:42.000000000 -0800 +++ net-drivers-2.5-exp/drivers/net/e100.c 2004-01-09 16:44:59.000000000 -0800 @@ -143,7 +143,6 @@ #include #include #include -#include #include #include #include @@ -273,11 +272,13 @@ }; enum scb_stat_ack { + stat_ack_not_ours = 0x00, stat_ack_sw_gen = 0x04, stat_ack_rnr = 0x10, stat_ack_cu_idle = 0x20, stat_ack_frame_rx = 0x40, stat_ack_cu_cmd_done = 0x80, + stat_ack_not_present = 0xFF, stat_ack_rx = (stat_ack_sw_gen | stat_ack_rnr | stat_ack_frame_rx), stat_ack_tx = (stat_ack_cu_idle | stat_ack_cu_cmd_done), }; @@ -367,11 +368,10 @@ u16 size; }; -struct rx_list { - struct list_head list; +struct rx { + struct rx *next, *prev; struct sk_buff *skb; dma_addr_t dma_addr; - unsigned int length; }; #if defined(__BIG_ENDIAN_BITFIELD) @@ -492,11 +492,13 @@ u32 msg_enable ____cacheline_aligned; struct net_device *netdev; struct pci_dev *pdev; - - struct list_head rx_list_head ____cacheline_aligned; - struct rx_list *rx_list; + + struct rx *rxs ____cacheline_aligned; + struct rx *rx_to_use; + struct rx *rx_to_clean; struct rfd blank_rfd; - + int ru_running; + spinlock_t cb_lock ____cacheline_aligned; spinlock_t cmd_lock; struct csr *csr; @@ -1350,57 +1352,46 @@ static inline void e100_start_receiver(struct nic *nic) { - /* (Re)start RU if suspended or idle and RFA is fully allocated */ - struct rx_list *curr = - list_entry(nic->rx_list_head.next, struct rx_list, list); - if(curr->skb) { - u8 status = readb(&nic->csr->scb.status); - if(unlikely((status & rus_mask) != rus_ready)) - e100_exec_cmd(nic, ruc_start, curr->dma_addr); + /* (Re)start RU if suspended or idle and RFA is non-NULL */ + if(!nic->ru_running && nic->rx_to_clean->skb) { + e100_exec_cmd(nic, ruc_start, nic->rx_to_clean->dma_addr); + nic->ru_running = 1; } } -static inline int e100_rx_alloc_skb(struct nic *nic, struct rx_list *curr) +#define RFD_BUF_LEN (sizeof(struct rfd) + VLAN_ETH_FRAME_LEN) +static inline int e100_rx_alloc_skb(struct nic *nic, struct rx *rx) { unsigned int rx_offset = 2; /* u32 align protocol headers */ - curr->dma_addr = 0; - curr->length = sizeof(struct rfd) + VLAN_ETH_FRAME_LEN; - - if(!(curr->skb = dev_alloc_skb(curr->length + rx_offset))) + if(!(rx->skb = dev_alloc_skb(RFD_BUF_LEN + rx_offset))) return -ENOMEM; - skb_reserve(curr->skb, rx_offset); - curr->skb->dev = nic->netdev; - curr->dma_addr = pci_map_single(nic->pdev, curr->skb->data, - curr->length, PCI_DMA_FROMDEVICE); - - return 0; -} - -static inline void e100_rx_rfa_add_tail(struct nic *nic, struct rx_list *curr) -{ - memcpy(curr->skb->data, &nic->blank_rfd, sizeof(struct rfd)); - pci_dma_sync_single(nic->pdev, curr->dma_addr, - sizeof(struct rfd), PCI_DMA_TODEVICE); + /* Align, init, and map the RFA. */ + rx->skb->dev = nic->netdev; + skb_reserve(rx->skb, rx_offset); + memcpy(rx->skb->data, &nic->blank_rfd, sizeof(struct rfd)); + rx->dma_addr = pci_map_single(nic->pdev, rx->skb->data, + RFD_BUF_LEN, PCI_DMA_FROMDEVICE); - if(likely(curr->list.prev != &nic->rx_list_head)) { - struct rx_list *prev = (struct rx_list *)curr->list.prev; - if(likely(prev->skb != NULL)) { - struct rfd *prev_rfd = (struct rfd *)prev->skb->data; - put_unaligned(cpu_to_le32(curr->dma_addr), - (u32 *)&prev_rfd->link); - prev_rfd->command = 0; - pci_dma_sync_single(nic->pdev, prev->dma_addr, - sizeof(struct rfd), PCI_DMA_TODEVICE); - } + /* Link the RFD to end of RFA by linking previous RFD to + * this one, and clearing EL bit of previous. */ + if(rx->prev->skb) { + struct rfd *prev_rfd = (struct rfd *)rx->prev->skb->data; + put_unaligned(cpu_to_le32(rx->dma_addr), + (u32 *)&prev_rfd->link); + prev_rfd->command &= ~cpu_to_le16(cb_el); + pci_dma_sync_single(nic->pdev, rx->prev->dma_addr, + sizeof(struct rfd), PCI_DMA_TODEVICE); } + + return 0; } -static inline int e100_rx_indicate(struct nic *nic, struct rx_list *curr, +static inline int e100_rx_indicate(struct nic *nic, struct rx *rx, unsigned int *work_done, unsigned int work_to_do) { - struct sk_buff *skb = curr->skb; + struct sk_buff *skb = rx->skb; struct rfd *rfd = (struct rfd *)skb->data; u16 rfd_status, actual_size; @@ -1408,7 +1399,7 @@ return -EAGAIN; /* Need to sync before taking a peek at cb_complete bit */ - pci_dma_sync_single(nic->pdev, curr->dma_addr, + pci_dma_sync_single(nic->pdev, rx->dma_addr, sizeof(struct rfd), PCI_DMA_FROMDEVICE); rfd_status = le16_to_cpu(rfd->status); @@ -1420,15 +1411,15 @@ /* Get actual data size */ actual_size = le16_to_cpu(rfd->actual_size) & 0x3FFF; - if(unlikely(actual_size > curr->length - sizeof(struct rfd))) - actual_size = curr->length - sizeof(struct rfd); + if(unlikely(actual_size > RFD_BUF_LEN - sizeof(struct rfd))) + actual_size = RFD_BUF_LEN - sizeof(struct rfd); /* Get data */ - pci_dma_sync_single(nic->pdev, curr->dma_addr, + pci_dma_sync_single(nic->pdev, rx->dma_addr, sizeof(struct rfd) + actual_size, PCI_DMA_FROMDEVICE); - pci_unmap_single(nic->pdev, curr->dma_addr, - curr->length, PCI_DMA_FROMDEVICE); + pci_unmap_single(nic->pdev, rx->dma_addr, + RFD_BUF_LEN, PCI_DMA_FROMDEVICE); /* Pull off the RFD and put the actual data (minus eth hdr) */ skb_reserve(skb, sizeof(struct rfd)); @@ -1452,37 +1443,26 @@ (*work_done)++; } - curr->length = 0; - curr->dma_addr = 0; - curr->skb = NULL; - + rx->skb = NULL; + return 0; } static inline void e100_rx_clean(struct nic *nic, unsigned int *work_done, unsigned int work_to_do) { - struct list_head *list, *tmp; - struct rx_list *curr; + struct rx *rx; /* Indicate newly arrived packets */ - list_for_each(list, &nic->rx_list_head) { - curr = list_entry(list, struct rx_list, list); - if(likely(curr->skb != NULL)) - if(e100_rx_indicate(nic, curr, work_done, work_to_do)) - break; + for(rx = nic->rx_to_clean; rx->skb; rx = nic->rx_to_clean = rx->next) { + if(e100_rx_indicate(nic, rx, work_done, work_to_do)) + break; /* No more to clean */ } /* Alloc new skbs to refill list */ - list_for_each_safe(list, tmp, &nic->rx_list_head) { - curr = list_entry(list, struct rx_list, list); - if(unlikely(curr->skb != NULL)) - break; /* List is full, done */ - if(unlikely(e100_rx_alloc_skb(nic, curr))) + for(rx = nic->rx_to_use; !rx->skb; rx = nic->rx_to_use = rx->next) { + if(unlikely(e100_rx_alloc_skb(nic, rx))) break; /* Better luck next time (see watchdog) */ - list_del(&curr->list); - list_add_tail(&curr->list, &nic->rx_list_head); - e100_rx_rfa_add_tail(nic, curr); } e100_start_receiver(nic); @@ -1490,44 +1470,47 @@ static void e100_rx_clean_list(struct nic *nic) { - struct list_head *list; - - if(!nic->rx_list) - return; + struct rx *rx; + unsigned int i, count = nic->params.rfds.count; - list_for_each(list, &nic->rx_list_head) { - struct rx_list *curr = list_entry(list, - struct rx_list, list); - if(curr->skb) { - pci_unmap_single(nic->pdev, curr->dma_addr, - curr->length, PCI_DMA_FROMDEVICE); - dev_kfree_skb(curr->skb); + if(nic->rxs) { + for(rx = nic->rxs, i = 0; i < count; rx++, i++) { + if(rx->skb) { + pci_unmap_single(nic->pdev, rx->dma_addr, + RFD_BUF_LEN, PCI_DMA_FROMDEVICE); + dev_kfree_skb(rx->skb); + } } + kfree(nic->rxs); + nic->rxs = NULL; } - kfree(nic->rx_list); - nic->rx_list = NULL; + nic->rx_to_use = nic->rx_to_clean = NULL; + nic->ru_running = 0; } static int e100_rx_alloc_list(struct nic *nic) { - struct rx_list *curr; + struct rx *rx; unsigned int i, count = nic->params.rfds.count; - - INIT_LIST_HEAD(&nic->rx_list_head); - if(!(nic->rx_list = kmalloc(sizeof(struct rx_list)*count, GFP_ATOMIC))) + nic->rx_to_use = nic->rx_to_clean = NULL; + + if(!(nic->rxs = kmalloc(sizeof(struct rx) * count, GFP_ATOMIC))) return -ENOMEM; + memset(nic->rxs, 0, sizeof(struct rx) * count); - for(curr = nic->rx_list, i = 0; i < count; curr++, i++) { - if(e100_rx_alloc_skb(nic, curr)) { + for(rx = nic->rxs, i = 0; i < count; rx++, i++) { + rx->next = (i + 1 < count) ? rx + 1 : nic->rxs; + rx->prev = (i == 0) ? nic->rxs + count - 1 : rx - 1; + if(e100_rx_alloc_skb(nic, rx)) { e100_rx_clean_list(nic); return -ENOMEM; } - list_add_tail(&curr->list, &nic->rx_list_head); - e100_rx_rfa_add_tail(nic, curr); } - + + nic->rx_to_use = nic->rx_to_clean = nic->rxs; + return 0; } @@ -1539,13 +1522,16 @@ DPRINTK(INTR, DEBUG, "stat_ack = 0x%02X\n", stat_ack); - if(stat_ack == 0x00 || /* Not our interrupt */ - stat_ack == 0xFF) /* Hardware is ejected (cardbus, hotswap) */ + if(stat_ack == stat_ack_not_ours || /* Not our interrupt */ + stat_ack == stat_ack_not_present) /* Hardware is ejected */ return IRQ_NONE; - /* Ack interrupts */ + /* Ack interrupt(s) */ writeb(stat_ack, &nic->csr->scb.stat_ack); - e100_write_flush(nic); + + /* We hit Receive No Resource (RNR); restart RU after cleaning */ + if(stat_ack & stat_ack_rnr) + nic->ru_running = 0; #ifdef CONFIG_E100_NAPI e100_disable_irq(nic); @@ -1664,7 +1650,7 @@ static void e100_down(struct nic *nic) { - e100_disable_irq(nic); + e100_hw_reset(nic); free_irq(nic->pdev->irq, nic->netdev); del_timer_sync(&nic->watchdog); netif_carrier_off(nic->netdev); @@ -1687,7 +1673,6 @@ { int err; struct sk_buff *skb; - struct rx_list *rx; /* Use driver resources to perform internal MAC or PHY * loopback test. A single packet is prepared and transmitted @@ -1724,8 +1709,8 @@ set_current_state(TASK_UNINTERRUPTIBLE); schedule_timeout(HZ / 100 + 1); - rx = list_entry(nic->rx_list_head.next, struct rx_list, list); - if(memcmp(rx->skb->data + sizeof(struct rfd), skb->data, ETH_DATA_LEN)) + if(memcmp(nic->rx_to_clean->skb->data + sizeof(struct rfd), + skb->data, ETH_DATA_LEN)) err = -EAGAIN; err_loopback_none: From scott.feldman@intel.com Tue Jan 13 10:55:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 10:56:02 -0800 (PST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DItm6H007950 for ; Tue, 13 Jan 2004 10:55:48 -0800 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: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0DIqhOv006961; Tue, 13 Jan 2004 18:52:43 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0DIslA6012031; Tue, 13 Jan 2004 18:54:47 GMT Received: from [134.134.3.50] ([134.134.3.50]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011310552613454 ; Tue, 13 Jan 2004 10:55:26 -0800 Date: Tue, 13 Jan 2004 11:31:55 -0800 (PST) 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: [e100 netdev-2.6 2/2] copyright + trailing blanks + misc 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: 2391 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 Content-Length: 17780 Lines: 649 * Misc: 2004 copyright, remove trailing white space, remove some unused symbols. ----------- --- net-drivers-2.5-exp/drivers/net/e100.c.orig 2004-01-09 16:46:20.000000000 -0800 +++ net-drivers-2.5-exp/drivers/net/e100.c 2004-01-09 16:50:02.000000000 -0800 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2003 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. 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 @@ -27,7 +27,7 @@ *******************************************************************************/ /* - * e100.c: Intel(R) PRO/100 ethernet driver + * e100.c: Intel(R) PRO/100 ethernet driver * * (Re)written 2003 by scott.feldman@intel.com. Based loosely on * original e100 driver, but better described as a munging of @@ -65,11 +65,11 @@ * through the Management Data Interface (MDI). Consequently, the * driver leverages the mii.c library shared with other MII-compliant * devices. - * - * Big- and Little-Endian byte order as well as 32- and 64-bit + * + * Big- and Little-Endian byte order as well as 32- and 64-bit * archs are supported. Weak-ordered memory and non-cache-coherent * archs are supported. - * + * * III. Transmit * * A Tx skb is mapped and hangs off of a TCB. TCBs are linked @@ -83,7 +83,7 @@ * Non-Tx commands (config, multicast setup, etc) are linked * into the CBL ring along with Tx commands. The common structure * used for both Tx and non-Tx commands is the Command Block (CB). - * + * * cb_to_use is the next CB to use for queuing a command; cb_to_clean * is the next CB to check for completion; cb_to_send is the first * CB to start on in case of a previous failure to resume. CB clean @@ -101,14 +101,14 @@ * Descriptors (RFD) + data buffer, thus forming the simplified mode * memory structure. Rx skbs are allocated to contain both the RFD * and the data buffer, but the RFD is pulled off before the skb is - * indicated. The data buffer is aligned such that encapsulated + * indicated. The data buffer is aligned such that encapsulated * protocol headers are u32-aligned. Since the RFD is part of the * mapped shared memory, and completion status is contained within * the RFD, the RFD must be dma_sync'ed to maintain a consistent * view from software and hardware. * * Under typical operation, the receive unit (RU) is start once, - * and the controller happily fills RFDs as frames arrive. If + * and the controller happily fills RFDs as frames arrive. If * replacement RFDs cannot be allocated, or the RU goes non-active, * the RU must be restarted. Frame arrival generates an interrupt, * and Rx indication and re-allocation happen in the same context, @@ -130,7 +130,7 @@ * * MagicPacket(tm) WoL support is enabled/disabled via ethtool. * - * Thanks to JC (jchapman@katalix.com) for helping with + * Thanks to JC (jchapman@katalix.com) for helping with * testing/troubleshooting the development driver. */ @@ -154,9 +154,9 @@ #define DRV_NAME "e100" -#define DRV_VERSION "3.0.12_dev" +#define DRV_VERSION "3.0.13_dev" #define DRV_DESCRIPTION "Intel(R) PRO/100 Network Driver" -#define DRV_COPYRIGHT "Copyright(c) 1999-2003 Intel Corporation" +#define DRV_COPYRIGHT "Copyright(c) 1999-2004 Intel Corporation" #define PFX DRV_NAME ": " #define E100_WATCHDOG_PERIOD 2 * HZ @@ -233,9 +233,9 @@ enum phy { phy_100a = 0x000003E0, - phy_100c = 0x035002A8, + phy_100c = 0x035002A8, phy_82555_tx = 0x015002A8, - phy_nsc_tx = 0x5C002000, + phy_nsc_tx = 0x5C002000, phy_82562_et = 0x033002A8, phy_82562_em = 0x032002A8, phy_82562_eh = 0x017002A8, @@ -260,15 +260,8 @@ }; enum scb_status { - rus_idle = 0x00, - rus_suspended = 0x04, - rus_no_resources = 0x08, rus_ready = 0x10, rus_mask = 0x3C, - cus_idle = 0x00, - cus_suspended = 0x40, - cus_active = 0x80, - cus_mask = 0xC0, }; enum scb_stat_ack { @@ -517,7 +510,7 @@ multicast_all = (1 << 2), wol_magic = (1 << 3), } flags ____cacheline_aligned; - + enum mac mac; enum phy phy; struct params params; @@ -544,7 +537,7 @@ u32 rx_fc_pause; u32 rx_fc_unsupported; u32 rx_tco_frames; - + u8 rev_id; u16 leds; u16 eeprom_wc; @@ -577,14 +570,14 @@ * device off of PCI bus */ writel(selective_reset, &nic->csr->port); e100_write_flush(nic); udelay(20); - + /* Now fully reset device */ writel(software_reset, &nic->csr->port); e100_write_flush(nic); udelay(20); - + /* TCO workaround - 82559 and greater */ if(nic->mac >= mac_82559_D101M) { - /* Issue a redundant CU load base without setting + /* Issue a redundant CU load base without setting * general pointer, and without waiting for scb to * clear. This gets us into post-driver. Finally, * wait 20 msec for reset to take effect. */ @@ -712,7 +705,7 @@ /* Try reading with an 8-bit addr len to discover actual addr len */ e100_eeprom_read(nic, &addr_len, 0); nic->eeprom_wc = 1 << addr_len; - + for(addr = 0; addr < nic->eeprom_wc; addr++) { nic->eeprom[addr] = e100_eeprom_read(nic, &addr_len, addr); if(addr < nic->eeprom_wc - 1) @@ -726,7 +719,7 @@ DPRINTK(PROBE, ERR, "EEPROM corrupted\n"); return -EAGAIN; } - + return 0; } @@ -738,10 +731,10 @@ /* Try reading with an 8-bit addr len to discover actual addr len */ e100_eeprom_read(nic, &addr_len, 0); nic->eeprom_wc = 1 << addr_len; - + if(start + count >= nic->eeprom_wc) return -EINVAL; - + for(addr = start; addr < start + count; addr++) e100_eeprom_write(nic, addr_len, addr, nic->eeprom[addr]); @@ -810,7 +803,7 @@ err = -ENOSPC; cb_prepare(nic, cb, skb); - + /* Order is important otherwise we'll be in a race with h/w: * set S-bit in current first, then clear S-bit in previous. */ cb->command |= cpu_to_le16(cb_s); @@ -849,7 +842,7 @@ if((data_out = readl(&nic->csr->mdi_ctrl)) & mdi_ready) break; } - + DPRINTK(HW, DEBUG, "%s:addr=%d, reg=%d, data_in=0x%04X, data_out=0x%04X\n", dir == mdi_read ? "READ" : "WRITE", addr, reg, data, data_out); @@ -877,9 +870,9 @@ if(nic->mac == mac_unknown) nic->mac = mac_82557_D100_A; - nic->params.rfds = rfds; - nic->params.cbs = cbs; - + nic->params.rfds = rfds; + nic->params.cbs = cbs; + /* Quadwords to DMA into FIFO before starting frame transmit */ nic->tx_threshold = 0xE0; @@ -905,9 +898,9 @@ u8 *c = (u8 *)config; cb->command = cpu_to_le16(cb_config); - + memset(config, 0, sizeof(struct config)); - + config->byte_count = 0x16; /* bytes in this struct */ config->rx_fifo_limit = 0x8; /* bytes in FIFO before DMA */ config->direct_rx_dma = 0x1; /* reserved */ @@ -938,7 +931,7 @@ if(nic->mii.force_media && nic->mii.full_duplex) config->full_duplex_force = 0x1; /* 1=force, 0=auto */ - + if(nic->flags & promiscuous || nic->loopback) { config->rx_save_bad_frames = 0x1; /* 1=save, 0=discard */ config->rx_discard_short_frames = 0x0; /* 1=discard, 0=save */ @@ -947,7 +940,7 @@ if(nic->flags & multicast_all) config->multicast_all = 0x1; /* 1=accept, 0=no */ - + if(!(nic->flags & wol_magic)) config->magic_packet_disable = 0x1; /* 1=off, 0=on */ @@ -961,7 +954,7 @@ else config->standard_stat_counter = 0x0; } - + DPRINTK(HW, DEBUG, "[00-07]=%02X:%02X:%02X:%02X:%02X:%02X:%02X:%02X\n", c[0], c[1], c[2], c[3], c[4], c[5], c[6], c[7]); DPRINTK(HW, DEBUG, "[08-15]=%02X:%02X:%02X:%02X:%02X:%02X:%02X:%02X\n", @@ -1007,7 +1000,7 @@ DPRINTK(HW, DEBUG, "phy_addr = %d\n", nic->mii.phy_id); if(addr == 32) return -EAGAIN; - + /* Selected the phy and isolate the rest */ for(addr = 0; addr < 32; addr++) { if(addr != nic->mii.phy_id) { @@ -1018,13 +1011,13 @@ bmcr & ~BMCR_ISOLATE); } } - + /* Get phy ID */ id_lo = mdio_read(netdev, nic->mii.phy_id, MII_PHYSID1); id_hi = mdio_read(netdev, nic->mii.phy_id, MII_PHYSID2); nic->phy = (u32)id_hi << 16 | (u32)id_lo; DPRINTK(HW, DEBUG, "phy ID = 0x%08X\n", nic->phy); - + /* Handle National tx phy */ if(nic->phy == phy_nsc_tx) { /* Disable congestion control */ @@ -1033,7 +1026,7 @@ cong &= ~NSC_CONG_ENABLE; mdio_write(netdev, nic->mii.phy_id, MII_NSC_CONG, cong); } - + if(nic->mac >= mac_82550_D102) /* enable/disable MDI/MDI-X auto-switching */ mdio_write(netdev, nic->mii.phy_id, MII_NCONFIG, @@ -1045,7 +1038,7 @@ static int e100_hw_init(struct nic *nic) { int err; - + e100_hw_reset(nic); DPRINTK(HW, ERR, "e100_hw_init\n"); @@ -1062,7 +1055,7 @@ return err; if((err = e100_exec_cb(nic, NULL, e100_setup_iaaddr))) return err; - if((err = e100_exec_cmd(nic, cuc_dump_addr, + if((err = e100_exec_cmd(nic, cuc_dump_addr, nic->dma_addr + offsetof(struct mem, stats)))) return err; if((err = e100_exec_cmd(nic, cuc_dump_reset, 0))) @@ -1117,7 +1110,7 @@ &s->complete; /* Device's stats reporting may take several microseconds to - * complete, so where always waiting for results of the + * complete, so where always waiting for results of the * previous command. */ if(*complete == le32_to_cpu(0x0000A007)) { @@ -1203,10 +1196,10 @@ } else if(!mii_link_ok(&nic->mii) && netif_carrier_ok(nic->netdev)) { DPRINTK(LINK, INFO, "link down\n"); } - + mii_check_link(&nic->mii); - - /* Software generated interrupt to recover from (rare) Rx + + /* Software generated interrupt to recover from (rare) Rx * allocation failure */ writeb(irq_sw_gen, &nic->csr->scb.cmd_hi); e100_write_flush(nic); @@ -1269,7 +1262,7 @@ for(cb = nic->cb_to_clean; cb->status & cpu_to_le16(cb_complete); cb = nic->cb_to_clean = cb->next) { - if(likely(cb->skb != NULL)) { + if(likely(cb->skb)) { nic->net_stats.tx_packets++; nic->net_stats.tx_bytes += cb->skb->len; @@ -1283,7 +1276,7 @@ cb->status = 0; nic->cbs_avail++; } - + spin_unlock(&nic->cb_lock); /* Recover from running out of Tx resources in xmit_frame */ @@ -1293,7 +1286,7 @@ return tx_cleaned; } -static void e100_clean_cbs(struct nic *nic, int free_mem) +static void e100_clean_cbs(struct nic *nic) { if(nic->cbs) { while(nic->cb_to_clean != nic->cb_to_use) { @@ -1308,13 +1301,11 @@ nic->cb_to_clean = nic->cb_to_clean->next; } nic->cbs_avail = nic->params.cbs.count; - if(free_mem) { - pci_free_consistent(nic->pdev, - sizeof(struct cb) * nic->params.cbs.count, - nic->cbs, nic->cbs_dma_addr); - nic->cbs = NULL; - nic->cbs_avail = 0; - } + pci_free_consistent(nic->pdev, + sizeof(struct cb) * nic->params.cbs.count, + nic->cbs, nic->cbs_dma_addr); + nic->cbs = NULL; + nic->cbs_avail = 0; } nic->cuc_cmd = cuc_start; nic->cb_to_use = nic->cb_to_send = nic->cb_to_clean = @@ -1325,25 +1316,25 @@ { struct cb *cb; unsigned int i, count = nic->params.cbs.count; - + nic->cuc_cmd = cuc_start; nic->cb_to_use = nic->cb_to_send = nic->cb_to_clean = NULL; nic->cbs_avail = 0; - - nic->cbs = pci_alloc_consistent(nic->pdev, + + nic->cbs = pci_alloc_consistent(nic->pdev, sizeof(struct cb) * count, &nic->cbs_dma_addr); if(!nic->cbs) return -ENOMEM; for(cb = nic->cbs, i = 0; i < count; cb++, i++) { cb->next = (i + 1 < count) ? cb + 1 : nic->cbs; - cb->prev = (i == 0) ? nic->cbs + count - 1 : cb - 1; - + cb->prev = (i == 0) ? nic->cbs + count - 1 : cb - 1; + cb->dma_addr = nic->cbs_dma_addr + i * sizeof(struct cb); cb->link = cpu_to_le32(nic->cbs_dma_addr + ((i+1) % count) * sizeof(struct cb)); } - + nic->cb_to_use = nic->cb_to_send = nic->cb_to_clean = nic->cbs; nic->cbs_avail = count; @@ -1617,7 +1608,7 @@ !(nic->eeprom[eeprom_config_asf] & eeprom_gcl) && ((nic->eeprom[eeprom_smbus_addr] & 0xFF) != 0xFE)); } - + static int e100_up(struct nic *nic) { int err; @@ -1642,7 +1633,7 @@ del_timer_sync(&nic->watchdog); netif_stop_queue(nic->netdev); err_clean_cbs: - e100_clean_cbs(nic, 1); + e100_clean_cbs(nic); err_rx_clean_list: e100_rx_clean_list(nic); return err; @@ -1655,7 +1646,7 @@ del_timer_sync(&nic->watchdog); netif_carrier_off(nic->netdev); netif_stop_queue(nic->netdev); - e100_clean_cbs(nic, 1); + e100_clean_cbs(nic); e100_rx_clean_list(nic); } @@ -1697,7 +1688,7 @@ BMCR_LOOPBACK); e100_start_receiver(nic); - + if(!(skb = dev_alloc_skb(ETH_DATA_LEN))) { err = -ENOMEM; goto err_loopback_none; @@ -1717,7 +1708,7 @@ mdio_write(nic->netdev, nic->mii.phy_id, MII_BMCR, 0); nic->loopback = lb_none; e100_hw_init(nic); - e100_clean_cbs(nic, 1); + e100_clean_cbs(nic); err_clean_rx: e100_rx_clean_list(nic); return err; @@ -1745,7 +1736,7 @@ struct nic *nic = netdev->priv; return mii_ethtool_gset(&nic->mii, cmd); } - + static int e100_set_settings(struct net_device *netdev, struct ethtool_cmd *cmd) { struct nic *nic = netdev->priv; @@ -1757,7 +1748,7 @@ return err; } - + static void e100_get_drvinfo(struct net_device *netdev, struct ethtool_drvinfo *info) { @@ -1767,7 +1758,7 @@ strcpy(info->fw_version, "N/A"); strcpy(info->bus_info, pci_name(nic->pdev)); } - + static int e100_get_regs_len(struct net_device *netdev) { struct nic *nic = netdev->priv; @@ -1805,11 +1796,11 @@ wol->supported = (nic->mac >= mac_82558_D101_A4) ? WAKE_MAGIC : 0; wol->wolopts = (nic->flags & wol_magic) ? WAKE_MAGIC : 0; } - + static int e100_set_wol(struct net_device *netdev, struct ethtool_wolinfo *wol) { struct nic *nic = netdev->priv; - + if(wol->wolopts != WAKE_MAGIC && wol->wolopts != 0) return -EOPNOTSUPP; @@ -1820,22 +1811,22 @@ pci_enable_wake(nic->pdev, 0, nic->flags & (wol_magic | e100_asf(nic))); e100_exec_cb(nic, NULL, e100_configure); - + return 0; } - + static u32 e100_get_msglevel(struct net_device *netdev) { struct nic *nic = netdev->priv; return nic->msg_enable; } - + static void e100_set_msglevel(struct net_device *netdev, u32 value) { struct nic *nic = netdev->priv; nic->msg_enable = value; } - + static int e100_nway_reset(struct net_device *netdev) { struct nic *nic = netdev->priv; @@ -1847,7 +1838,7 @@ struct nic *nic = netdev->priv; return mii_link_ok(&nic->mii); } - + static int e100_get_eeprom_len(struct net_device *netdev) { struct nic *nic = netdev->priv; @@ -1859,7 +1850,7 @@ struct ethtool_eeprom *eeprom, u8 *bytes) { struct nic *nic = netdev->priv; - + eeprom->magic = E100_EEPROM_MAGIC; memcpy(bytes, &((u8 *)nic->eeprom)[eeprom->offset], eeprom->len); @@ -1870,7 +1861,7 @@ struct ethtool_eeprom *eeprom, u8 *bytes) { struct nic *nic = netdev->priv; - + if(eeprom->magic != E100_EEPROM_MAGIC) return -EINVAL; memcpy(&((u8 *)nic->eeprom)[eeprom->offset], bytes, eeprom->len); @@ -1885,7 +1876,7 @@ struct nic *nic = netdev->priv; struct param_range *rfds = &nic->params.rfds; struct param_range *cbs = &nic->params.cbs; - + ring->rx_max_pending = rfds->max; ring->tx_max_pending = cbs->max; ring->rx_mini_max_pending = 0; @@ -1895,14 +1886,14 @@ ring->rx_mini_pending = 0; ring->rx_jumbo_pending = 0; } - + static int e100_set_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring) { struct nic *nic = netdev->priv; struct param_range *rfds = &nic->params.rfds; struct param_range *cbs = &nic->params.cbs; - + if(netif_running(netdev)) e100_down(nic); rfds->count = max(ring->rx_pending, rfds->min); @@ -1911,11 +1902,11 @@ cbs->count = min(cbs->count, cbs->max); if(netif_running(netdev)) e100_up(nic); - + return 0; } - -static char e100_gstrings_test[][ETH_GSTRING_LEN] = { + +static const char e100_gstrings_test[][ETH_GSTRING_LEN] = { "Link test (on/offline)", "Eeprom test (on/offline)", "Self test (offline)", @@ -1966,7 +1957,7 @@ return 0; } -static char e100_gstrings_stats[][ETH_GSTRING_LEN] = { +static const char e100_gstrings_stats[][ETH_GSTRING_LEN] = { "rx_packets", "tx_packets", "rx_bytes", "tx_bytes", "rx_errors", "tx_errors", "rx_dropped", "tx_dropped", "multicast", "collisions", "rx_length_errors", "rx_over_errors", "rx_crc_errors", @@ -1974,7 +1965,7 @@ "tx_aborted_errors", "tx_carrier_errors", "tx_fifo_errors", "tx_heartbeat_errors", "tx_window_errors", /* device-specific stats */ - "tx_deferred", "tx_single_collisions", "tx_multi_collisions", + "tx_deferred", "tx_single_collisions", "tx_multi_collisions", "tx_flow_control_pause", "rx_flow_control_pause", "rx_flow_control_unsupported", "tx_tco_packets", "rx_tco_packets", }; @@ -2083,13 +2074,13 @@ return 0; } -static int __devinit e100_probe(struct pci_dev *pdev, +static int __devinit e100_probe(struct pci_dev *pdev, const struct pci_device_id *ent) { struct net_device *netdev; struct nic *nic; int err; - + if(!(netdev = alloc_etherdev(sizeof(struct nic)))) { if(((1 << debug) - 1) & NETIF_MSG_PROBE) printk(KERN_ERR PFX "Etherdev alloc failed, abort.\n"); @@ -2241,7 +2232,7 @@ } } -#ifdef CONFIG_PM +#ifdef CONFIG_PM static int e100_suspend(struct pci_dev *pdev, u32 state) { struct net_device *netdev = pci_get_drvdata(pdev); @@ -2272,7 +2263,7 @@ netif_device_attach(netdev); if(netif_running(netdev)) e100_up(nic); - + return 0; } #endif @@ -2282,7 +2273,7 @@ .id_table = e100_id_table, .probe = e100_probe, .remove = __devexit_p(e100_remove), -#ifdef CONFIG_PM +#ifdef CONFIG_PM .suspend = e100_suspend, .resume = e100_resume, #endif From shemminger@osdl.org Tue Jan 13 11:03:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 11:03:49 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DJ3Y6H008521 for ; Tue, 13 Jan 2004 11:03:35 -0800 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 i0DJ3Mo12739; Tue, 13 Jan 2004 11:03:22 -0800 Date: Tue, 13 Jan 2004 11:00:39 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-hams@vger.kernel.org Subject: [PATCH] (4/5) remove bpqether pre-existing device discovery loop Message-Id: <20040113110039.647711c9.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (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: 2392 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 Content-Length: 1286 Lines: 47 Remove duplicate/conflicting code now that netdev_register_notifier replays the device registration events. Reorder initialization to avoid having to simplify error unwind if /proc creation failed. diff -Nru a/drivers/net/hamradio/bpqether.c b/drivers/net/hamradio/bpqether.c --- a/drivers/net/hamradio/bpqether.c Tue Jan 13 10:23:55 2004 +++ b/drivers/net/hamradio/bpqether.c Tue Jan 13 10:23:55 2004 @@ -606,33 +606,20 @@ */ static int __init bpq_init_driver(void) { - struct net_device *dev; - - dev_add_pack(&bpq_packet_type); - - register_netdevice_notifier(&bpq_dev_notifier); - - printk(banner); - #ifdef CONFIG_PROC_FS if (!proc_net_fops_create("bpqether", S_IRUGO, &bpq_info_fops)) { printk(KERN_ERR "bpq: cannot create /proc/net/bpqether entry.\n"); - unregister_netdevice_notifier(&bpq_dev_notifier); - dev_remove_pack(&bpq_packet_type); return -ENOENT; } #endif /* CONFIG_PROC_FS */ - rtnl_lock(); - for (dev = dev_base; dev != NULL; dev = dev->next) { - if (dev_is_ethdev(dev) && bpq_new_device(dev)) { - printk(KERN_ERR - "bpq: cannot setup dev for '%s'\n", - dev->name); - } - } - rtnl_unlock(); + dev_add_pack(&bpq_packet_type); + + register_netdevice_notifier(&bpq_dev_notifier); + + printk(banner); + return 0; } From shemminger@osdl.org Tue Jan 13 11:03:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 11:03:55 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DJ3b6H008525 for ; Tue, 13 Jan 2004 11:03:38 -0800 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 i0DJ3Qo12762; Tue, 13 Jan 2004 11:03:26 -0800 Date: Tue, 13 Jan 2004 10:58:56 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (2/5) IPV6 notifier replay changes Message-Id: <20040113105856.3e366b9c.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (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: 2396 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 Content-Length: 4676 Lines: 177 Change IPV6 to handle the new case where netdev events are replayed on registration: * change code ordering so address configuration is ready before registration (this was actually a bug in existing code) * take out code that capture's existing devices, this is now done in the replay * make notifier code local to addrconf.c so it can be have smaller scope diff -Nru a/include/net/addrconf.h b/include/net/addrconf.h --- a/include/net/addrconf.h Thu Dec 18 15:42:20 2003 +++ b/include/net/addrconf.h Thu Dec 18 15:42:20 2003 @@ -50,10 +50,6 @@ extern void addrconf_init(void); extern void addrconf_cleanup(void); -extern int addrconf_notify(struct notifier_block *this, - unsigned long event, - void * data); - extern int addrconf_add_ifaddr(void *arg); extern int addrconf_del_ifaddr(void *arg); extern int addrconf_set_dstaddr(void *arg); diff -Nru a/include/net/ipv6.h b/include/net/ipv6.h --- a/include/net/ipv6.h Thu Dec 18 15:42:20 2003 +++ b/include/net/ipv6.h Thu Dec 18 15:42:20 2003 @@ -408,11 +408,7 @@ extern void ipv6_packet_init(void); -extern void ipv6_netdev_notif_init(void); - extern void ipv6_packet_cleanup(void); - -extern void ipv6_netdev_notif_cleanup(void); extern int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len); extern void ipv6_icmp_error(struct sock *sk, struct sk_buff *skb, int err, u16 port, diff -Nru a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c --- a/net/ipv6/addrconf.c Thu Dec 18 15:42:20 2003 +++ b/net/ipv6/addrconf.c Thu Dec 18 15:42:20 2003 @@ -1810,8 +1810,8 @@ } -int addrconf_notify(struct notifier_block *this, unsigned long event, - void * data) +static int addrconf_notify(struct notifier_block *this, unsigned long event, + void * data) { struct net_device *dev = (struct net_device *) data; struct inet6_dev *idev = __in6_dev_get(dev); @@ -1881,6 +1881,14 @@ return NOTIFY_OK; } +/* + * addrconf module should be notified of a device going up + */ +static struct notifier_block ipv6_dev_notf = { + .notifier_call = addrconf_notify, + .priority = 0 +}; + static int addrconf_ifdown(struct net_device *dev, int how) { struct inet6_dev *idev; @@ -3126,9 +3134,7 @@ void __init addrconf_init(void) { -#ifdef MODULE - struct net_device *dev; -#endif + register_netdevice_notifier(&ipv6_dev_notf); #ifdef CONFIG_IPV6_PRIVACY md5_tfm = crypto_alloc_tfm("md5", 0); @@ -3137,30 +3143,6 @@ "failed to load transform for md5\n"); #endif -#ifdef MODULE - /* This takes sense only during module load. */ - rtnl_lock(); - for (dev = dev_base; dev; dev = dev->next) { - if (!(dev->flags&IFF_UP)) - continue; - - switch (dev->type) { - case ARPHRD_LOOPBACK: - init_loopback(dev); - break; - case ARPHRD_ETHER: - case ARPHRD_FDDI: - case ARPHRD_IEEE802_TR: - case ARPHRD_ARCNET: - addrconf_dev_config(dev); - break; - default:; - /* Ignore all other */ - } - } - rtnl_unlock(); -#endif - addrconf_verify(0); rtnetlink_links[PF_INET6] = inet6_rtnetlink_table; #ifdef CONFIG_SYSCTL @@ -3178,6 +3160,8 @@ struct inet6_ifaddr *ifa; int i; + unregister_netdevice_notifier(&ipv6_dev_notf); + rtnetlink_links[PF_INET6] = NULL; #ifdef CONFIG_SYSCTL addrconf_sysctl_unregister(&ipv6_devconf_dflt); @@ -3231,3 +3215,4 @@ #endif } #endif /* MODULE */ + diff -Nru a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c --- a/net/ipv6/af_inet6.c Thu Dec 18 15:42:20 2003 +++ b/net/ipv6/af_inet6.c Thu Dec 18 15:42:20 2003 @@ -802,7 +802,6 @@ if (if6_proc_init()) goto proc_if6_fail; #endif - ipv6_netdev_notif_init(); ipv6_packet_init(); ip6_route_init(); ip6_flowlabel_init(); @@ -869,7 +868,6 @@ #endif /* Cleanup code parts. */ sit_cleanup(); - ipv6_netdev_notif_cleanup(); ip6_flowlabel_cleanup(); addrconf_cleanup(); ip6_route_cleanup(); diff -Nru a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c --- a/net/ipv6/ipv6_sockglue.c Thu Dec 18 15:42:20 2003 +++ b/net/ipv6/ipv6_sockglue.c Thu Dec 18 15:42:20 2003 @@ -62,14 +62,6 @@ .func = ipv6_rcv, }; -/* - * addrconf module should be notified of a device going up - */ -static struct notifier_block ipv6_dev_notf = { - .notifier_call = addrconf_notify, - .priority = 0 -}; - struct ip6_ra_chain *ip6_ra_chain; rwlock_t ip6_ra_lock = RW_LOCK_UNLOCKED; @@ -707,19 +699,9 @@ dev_add_pack(&ipv6_packet_type); } -void __init ipv6_netdev_notif_init(void) -{ - register_netdevice_notifier(&ipv6_dev_notf); -} - #ifdef MODULE void ipv6_packet_cleanup(void) { dev_remove_pack(&ipv6_packet_type); -} - -void ipv6_netdev_notif_cleanup(void) -{ - unregister_netdevice_notifier(&ipv6_dev_notf); } #endif From shemminger@osdl.org Tue Jan 13 11:03:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 11:03:51 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DJ3a6H008522 for ; Tue, 13 Jan 2004 11:03:36 -0800 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 i0DJ3No12745; Tue, 13 Jan 2004 11:03:23 -0800 Date: Tue, 13 Jan 2004 11:01:03 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, Henner Eisen , linux-x25@vger.kernel.org Subject: [PATCH] (3/5) remove X25 pre-existing device discovery loop Message-Id: <20040113110103.4a36c0d1.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (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: 2393 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 Content-Length: 977 Lines: 40 Remove duplicate/conflicting code now that netdev_register_notifier replays the device registration events. diff -Nru a/net/x25/af_x25.c b/net/x25/af_x25.c --- a/net/x25/af_x25.c Mon Jan 12 14:22:07 2004 +++ b/net/x25/af_x25.c Mon Jan 12 14:22:07 2004 @@ -1372,9 +1372,6 @@ static int __init x25_init(void) { -#ifdef MODULE - struct net_device *dev; -#endif /* MODULE */ sock_register(&x25_family_ops); dev_add_pack(&x25_packet_type); @@ -1386,23 +1383,7 @@ #ifdef CONFIG_SYSCTL x25_register_sysctl(); #endif - x25_proc_init(); -#ifdef MODULE - /* - * Register any pre existing devices. - */ - read_lock(&dev_base_lock); - for (dev = dev_base; dev; dev = dev->next) { - if ((dev->flags & IFF_UP) && (dev->type == ARPHRD_X25 -#if defined(CONFIG_LLC) || defined(CONFIG_LLC_MODULE) - || dev->type == ARPHRD_ETHER -#endif - )) - x25_link_device_up(dev); - } - read_unlock(&dev_base_lock); -#endif /* MODULE */ return 0; } module_init(x25_init); From shemminger@osdl.org Tue Jan 13 11:03:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 11:03:54 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DJ3b6H008524 for ; Tue, 13 Jan 2004 11:03:37 -0800 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 i0DJ3Oo12752; Tue, 13 Jan 2004 11:03:24 -0800 Date: Tue, 13 Jan 2004 11:01:47 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, Nenad Corbic Subject: [PATCH] (5/5) lapbether remove pre-existing device discovery loop Message-Id: <20040113110147.641bf4e1.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (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: 2394 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 Content-Length: 677 Lines: 28 Remove duplicate/conflicting code now that netdev_register_notifier replays the device registration events. diff -Nru a/drivers/net/wan/lapbether.c b/drivers/net/wan/lapbether.c --- a/drivers/net/wan/lapbether.c Tue Jan 13 10:26:01 2004 +++ b/drivers/net/wan/lapbether.c Tue Jan 13 10:26:01 2004 @@ -448,21 +448,11 @@ static int __init lapbeth_init_driver(void) { - struct net_device *dev; - dev_add_pack(&lapbeth_packet_type); register_netdevice_notifier(&lapbeth_dev_notifier); printk(banner); - - rtnl_lock(); - for (dev = dev_base; dev; dev = dev->next) { - if (dev_is_ethdev(dev)) { - lapbeth_new_device(dev); - } - } - rtnl_unlock(); return 0; } From shemminger@osdl.org Tue Jan 13 11:03:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 11:03:55 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DJ3b6H008523 for ; Tue, 13 Jan 2004 11:03:37 -0800 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 i0DJ3Qo12758; Tue, 13 Jan 2004 11:03:26 -0800 Date: Tue, 13 Jan 2004 10:58:43 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (1/5) replay netdev notifier events on registration Message-Id: <20040113105843.0d1351cb.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (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: 2395 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 Content-Length: 1648 Lines: 48 Several protocols register for network device notification to detect new new network devices; but then have to walk the device list to capture the devices that are already up. This leaves a exposed window between when the notifier is registered and when the list walk occurs. Also, in several cases, there is a different code path for the pre-existing and new devices which leads to bug exposure. The solution is to replay the registration and up events for existing devices into the new notifier. All notifiers in 2.6.1 have been audited and the other patches fix places where protocols were doing there own registered device discovery loop. Thanks to Al Viro for the suggestion. diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Thu Dec 18 15:32:11 2003 +++ b/net/core/dev.c Thu Dec 18 15:32:11 2003 @@ -946,11 +946,29 @@ * The notifier passed is linked into the kernel structures and must * not be reused until it has been unregistered. A negative errno code * is returned on a failure. + * + * When registered all registration and up events are replayed + * to the new notifier to allow device to have a race free + * view of the network device list. */ int register_netdevice_notifier(struct notifier_block *nb) { - return notifier_chain_register(&netdev_chain, nb); + struct net_device *dev; + int err; + + rtnl_lock(); + err = notifier_chain_register(&netdev_chain, nb); + if (!err) { + for (dev = dev_base; dev; dev = dev->next) { + nb->notifier_call(nb, NETDEV_REGISTER, dev); + + if (dev->flags & IFF_UP) + nb->notifier_call(nb, NETDEV_UP, dev); + } + } + rtnl_unlock(); + return err; } /** From Robert.Olsson@data.slu.se Tue Jan 13 11:10:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 11:10:45 -0800 (PST) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DJAV6H010477 for ; Tue, 13 Jan 2004 11:10:32 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i0DJ9R6q013054; Tue, 13 Jan 2004 20:09:27 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 112DDEC26F; Tue, 13 Jan 2004 20:09:27 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16388.16999.36698.328251@robur.slu.se> Date: Tue, 13 Jan 2004 20:09:27 +0100 To: Jeff Garzik Cc: Robert Olsson , Greg Banks , "David S. Miller" , Linux Network Development list , jchapman@katalix.com Subject: Re: [PATCH] make tg3 NAPI support configurable In-Reply-To: <4000ABBA.50601@pobox.com> References: <3FE2F3A7.2A109F28@melbourne.sgi.com> <16354.64258.364153.488309@robur.slu.se> <4000ABBA.50601@pobox.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-archive-position: 2397 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: 3020 Lines: 94 Jeff Garzik writes: > > Furthermore NAPI can be extended to schedule dev->poll even for TX- > > interrupts. There is pacth for e1000 doing this. We see about 5-8% > > overall system packet improvement with this. > > tg3 already schedules for TX, so we've got that part covered :) Hello! I was thinking of a variant JC [jchapman@katalix.com] mentioned on this list some time ago. He also sent me the patch for e1000. A test and the patch is below. Routing test. ============ 2 * 10 Million pkts @ 2*783 kpps into eth0, eth2 routed to eth1, eth3. (TX-OK is the number to look for) Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags eth0 1500 0 3494625 8258316 8258316 6505378 24 0 0 0 BRU eth1 1500 0 45 0 0 0 3494627 0 0 0 BRU eth2 1500 0 3493930 8270692 8270692 6506073 21 0 0 0 BRU eth3 1500 0 1 0 0 0 3493929 0 0 0 BRU CPU0 26: 74 IO-APIC-level eth0 27: 48617 IO-APIC-level eth1 28: 71 IO-APIC-level eth2 29: 48659 IO-APIC-level eth3 ------------------------------------------------------------------------------- With patch. Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags eth0 1500 0 3752858 8151787 8151787 6247146 23 0 0 0 BRU eth1 1500 0 47 0 0 0 3751676 0 0 0 BRU eth2 1500 0 3751226 8191511 8191511 6248777 21 0 0 0 BRU eth3 1500 0 1 0 0 0 3750490 0 0 0 BRU CPU0 26: 125 IO-APIC-level eth0 27: 127 IO-APIC-level eth1 28: 122 IO-APIC-level eth2 29: 137 IO-APIC-level eth3 TX interrupts alone now schedules consecutive polls. We route 7.5 Million pkts w/o any interrupts. Total throughput from 0.349% to 0.375% (~580 kpps) Of course having having RX-only and TX-only is special case... TCP-stream test. ================ Netperf w. single TCP-stream recv showed 938 Mbit/s both with and without patch and interrupts rates were the same. XEON @ 2.66 GHz w. e1000 4-port board. Linux 2.6.0-test11/UP --- e1000_main.c.orig 2003-08-26 22:59:00.000000000 +0100 +++ e1000_main.c 2003-08-26 23:03:35.000000000 +0100 @@ -2061,19 +2061,21 @@ struct e1000_adapter *adapter = netdev->priv; int work_to_do = min(*budget, netdev->quota); int work_done = 0; - - e1000_clean_tx_irq(adapter); + boolean_t tx_cleaned; + + tx_cleaned = e1000_clean_tx_irq(adapter); e1000_clean_rx_irq(adapter, &work_done, work_to_do); - *budget -= work_done; - netdev->quota -= work_done; - - if(work_done < work_to_do) { + if(!tx_cleaned && (work_done == 0)) { netif_rx_complete(netdev); e1000_irq_enable(adapter); + return 0; } - return (work_done >= work_to_do); + *budget -= work_done; + netdev->quota -= work_done; + + return 1; } #endif Cheers. --ro From hk@hkit.de Tue Jan 13 12:44:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 12:44:23 -0800 (PST) Received: from imail.paderlinx.de (mail.paderlinx.de [62.52.113.5]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DKi96H029182 for ; Tue, 13 Jan 2004 12:44:10 -0800 Received: from [192.168.0.201] ([217.187.158.177]) by imail.paderlinx.de (Netscape Messaging Server 4.15) with ESMTP id HRG49E00.K1H; Tue, 13 Jan 2004 21:44:02 +0100 Mime-Version: 1.0 (Apple Message framework v609) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary="Apple-Mail-7--917323085" Message-Id: <37AE57B8-4609-11D8-8E0C-000393BE213C@hkit.de> Content-Transfer-Encoding: 7bit Cc: c-d.hailfinger.kernel.2003@gmx.net From: Hubertus Krogmann Subject: Date: Tue, 13 Jan 2004 21:44:01 +0100 To: netdev@oss.sgi.com X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.609) X-archive-position: 2398 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hk@hkit.de Precedence: bulk X-list: netdev Content-Length: 2750 Lines: 75 --Apple-Mail-7--917323085 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hello Thanx 1st for providing this forcedeth driver. It works on my MSI nforce board force:~ # lspci 00:00.0 Host bridge: nVidia Corporation nForce CPU bridge (rev b2) 00:00.1 RAM memory: nVidia Corporation nForce 220/420 Memory Controller (rev b2) 00:00.2 RAM memory: nVidia Corporation nForce 220/420 Memory Controller (rev b2) 00:00.3 RAM memory: nVidia Corporation nForce 420 Memory Controller (DDR) (rev b2) 00:01.0 ISA bridge: nVidia Corporation nForce ISA Bridge (rev c3) 00:01.1 SMBus: nVidia Corporation nForce PCI System Management (rev c1) 00:02.0 USB Controller: nVidia Corporation nForce USB Controller (rev c3) 00:03.0 USB Controller: nVidia Corporation nForce USB Controller (rev c3) 00:04.0 Ethernet controller: nVidia Corporation nForce Ethernet Controller (rev c2) 00:05.0 Multimedia audio controller: nVidia Corporation: Unknown device 01b0 (rev c2) 00:06.0 Multimedia audio controller: nVidia Corporation nForce Audio (rev c2) 00:08.0 PCI bridge: nVidia Corporation nForce PCI-to-PCI bridge (rev c2) 00:09.0 IDE interface: nVidia Corporation nForce IDE (rev c3) 00:1e.0 PCI bridge: nVidia Corporation nForce AGP to PCI Bridge (rev b2) 01:01.0 FireWire (IEEE 1394): Texas Instruments TSB12LV26 IEEE-1394 Controller (Link) 01:03.0 SCSI storage controller: LSI Logic / Symbios Logic 53c860 (rev 02) 02:00.0 VGA compatible controller: nVidia Corporation NVCrush11 [GeForce2 MX Integrated Graphics] (rev b1) I do have a problem, my system hangs sometimes for about 5-10 seconds. While I ping my system : no hangs Start ping while it hangs : hang is over immediately. That is why I will try your driver. Anything I may test ? Another PC w2k and a Apple iBook can be used with a SMC router with integrated 4 port switch... -- Hubertus Krogmann -- hk @ hkit . de -- www . hkit . de GPG Fingerprint 42 F9 76 30 C0 E6 A5 59 AE F9 DD 12 A2 29 69 2F --Apple-Mail-7--917323085 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iQEVAwUBQARYl/ME5VGxtm9BAQGwJwgAu3SMEwLKah1T2D3+BlD8OahL7aNRG1th 2nKdbcfzwlozwrLvZyQiQ+f3kGgtNRJRTo4OVXIHGyHzYKg6W8pmg/j72A0ryCZm EWvE6ZBpyWBpcNII5HeBy3v02Cy7s7OpPefLJFAa4WnWT/Mc+js0UBOIP6gywZbz uTPr7C8jQK0RJv4P2ernDy0gDJF3IFvyTgpqK7XGWnheelxmYz+06nMT1q9hc6s5 vh8SSrMbp0w6rNtd9JNyFTd1B7Ov8zorzsTVeMVS0FHH5sGjVpSL14OhASmGxrYE aCxZUIhwj7er88xJBtMUGFYNW2UL2+2HRCV9+CStWb5shYbD3IqDqA== =5BO/ -----END PGP SIGNATURE----- --Apple-Mail-7--917323085-- From krkumar@us.ibm.com Tue Jan 13 13:29:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 13:30:05 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DLTi6H030749 for ; Tue, 13 Jan 2004 13:29:45 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0DLTdd6418922; Tue, 13 Jan 2004 16:29:39 -0500 Received: from linux-udp15191261uds.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0DLTbh5226522; Tue, 13 Jan 2004 16:29:38 -0500 Date: Tue, 13 Jan 2004 13:21:19 -0800 (PST) From: Krishna Kumar X-X-Sender: krkumar@linux-udp14999547uds To: "David S. Miller" cc: Krishna Kumar , Subject: [PATCH 1/5] ipcomp_tunnel_create doesn't set tunnel state In-Reply-To: <20040110121134.08481951.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2399 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 724 Lines: 27 > > Or should I send separate patches this time ? > > I think this would be a good idea. ipcomp_tunnel_create doesn't set x->km.state to XFRM_STATE_DEAD. This can lead to the BUG_TRAP in __xfrm_state_destroy when xfrm_state_put() finds this is the last reference. This was reported as one of the symptoms of [Bug 1754] some time back. thanks, - KK diff -ruN linux-2.6.0-rc2-bk6.org/net/ipv4/ipcomp.c linux-2.6.0-rc2-bk6/net/ipv4/ipcomp.c --- linux-2.6.0-rc2-bk6.org/net/ipv4/ipcomp.c 2004-01-05 13:43:50.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/ipv4/ipcomp.c 2004-01-09 13:00:22.000000000 -0800 @@ -294,6 +294,7 @@ return t; error: + t->km.state = XFRM_STATE_DEAD; xfrm_state_put(t); t = NULL; goto out; From krkumar@us.ibm.com Tue Jan 13 13:31:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 13:31:15 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DLV16H031092 for ; Tue, 13 Jan 2004 13:31:02 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0DLUud6287540; Tue, 13 Jan 2004 16:30:56 -0500 Received: from linux-udp15191261uds.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0DLUsh5189858; Tue, 13 Jan 2004 16:30:55 -0500 Date: Tue, 13 Jan 2004 13:22:36 -0800 (PST) From: Krishna Kumar X-X-Sender: krkumar@linux-udp14999547uds To: "David S. Miller" cc: netdev@oss.sgi.com Subject: [PATCH 2/5] Bad dereference of xfrm_state in pf_key In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2400 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1267 Lines: 39 In pfkey_get(), the xfrm_state is dereferenced after it is dropped, which could lead to dereferencing freed memory. This can also be done by dropping the reference before the pfkey_broadcast() and in the IS_ERR case. thanks, - KK diff -ruN linux-2.6.0-rc2-bk6.org/net/key/af_key.c linux-2.6.0-rc2-bk6/net/key/af_key.c --- linux-2.6.0-rc2-bk6.org/net/key/af_key.c 2004-01-05 13:45:47.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/key/af_key.c 2004-01-09 12:41:30.000000000 -0800 @@ -1283,6 +1283,7 @@ static int pfkey_get(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { + __u8 proto; struct sk_buff *out_skb; struct sadb_msg *out_hdr; struct xfrm_state *x; @@ -1297,6 +1298,7 @@ return -ESRCH; out_skb = pfkey_xfrm_state2msg(x, 1, 3); + proto = x->id.proto; xfrm_state_put(x); if (IS_ERR(out_skb)) return PTR_ERR(out_skb); @@ -1304,7 +1306,7 @@ out_hdr = (struct sadb_msg *) out_skb->data; out_hdr->sadb_msg_version = hdr->sadb_msg_version; out_hdr->sadb_msg_type = SADB_DUMP; - out_hdr->sadb_msg_satype = pfkey_proto2satype(x->id.proto); + out_hdr->sadb_msg_satype = pfkey_proto2satype(proto); out_hdr->sadb_msg_errno = 0; out_hdr->sadb_msg_reserved = 0; out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; From krkumar@us.ibm.com Tue Jan 13 13:32:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 13:32:16 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DLW16H031495 for ; Tue, 13 Jan 2004 13:32:03 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i0DLVtKc176414; Tue, 13 Jan 2004 16:31:55 -0500 Received: from linux-udp15191261uds.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0DLVrh5185430; Tue, 13 Jan 2004 16:31:54 -0500 Date: Tue, 13 Jan 2004 13:23:35 -0800 (PST) From: Krishna Kumar X-X-Sender: krkumar@linux-udp14999547uds To: "David S. Miller" cc: netdev@oss.sgi.com Subject: [PATCH 3/5] xfrm_lookup bugs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2401 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1452 Lines: 50 In xfrm_lookup, a couple of bugs : - the found or allocated xfrm_states are not passed correctly to xfrm_bundle_create (and to the subsequent frees in case of create failing) if the first xfrm_tmpl_resolve failed and the second one succeeded. - error handling is wrong. thanks, - KK diff -ruN linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_policy.c linux-2.6.0-rc2-bk6/net/xfrm/xfrm_policy.c --- linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_policy.c 2004-01-09 12:42:53.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/xfrm/xfrm_policy.c 2004-01-12 09:55:26.000000000 -0800 @@ -783,25 +783,27 @@ __set_task_state(tsk, TASK_INTERRUPTIBLE); add_wait_queue(&km_waitq, &wait); - err = xfrm_tmpl_resolve(policy, fl, xfrm, family); - if (err == -EAGAIN) + nx = xfrm_tmpl_resolve(policy, fl, xfrm, family); + if (nx == -EAGAIN) schedule(); __set_task_state(tsk, TASK_RUNNING); remove_wait_queue(&km_waitq, &wait); - if (err == -EAGAIN && signal_pending(current)) { + if (nx == -EAGAIN && signal_pending(current)) { err = -ERESTART; goto error; } - if (err == -EAGAIN || + if (nx == -EAGAIN || genid != atomic_read(&flow_cache_genid)) { xfrm_pol_put(policy); goto restart; } + err = nx; } - if (err) + if (err < 0) goto error; - } else if (nx == 0) { + } + if (nx == 0) { /* Flow passes not transformed. */ xfrm_pol_put(policy); return 0; From krkumar@us.ibm.com Tue Jan 13 13:32:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 13:33:03 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DLWn6H031754 for ; Tue, 13 Jan 2004 13:32:49 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0DLWhg6571464; Tue, 13 Jan 2004 16:32:43 -0500 Received: from linux-udp15191261uds.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0DLWfh5222660; Tue, 13 Jan 2004 16:32:42 -0500 Date: Tue, 13 Jan 2004 13:24:23 -0800 (PST) From: Krishna Kumar X-X-Sender: krkumar@linux-udp14999547uds To: "David S. Miller" cc: netdev@oss.sgi.com, KK Subject: [PATCH 4/5] xfrm_state_construct doesn't set tunnel state In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2402 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 651 Lines: 22 xfrm_state_construct doesn't set x->km.state to XFRM_STATE_DEAD. This can lead to the BUG_TRAP in __xfrm_state_destroy when xfrm_state_put() finds this is the last reference. This was reported as one of the symptoms of [Bug 1754] some time back. thanks, - KK diff -ruN linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_user.c linux-2.6.0-rc2-bk6/net/xfrm/xfrm_user.c --- linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_user.c 2004-01-09 12:57:42.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/xfrm/xfrm_user.c 2004-01-09 12:59:00.000000000 -0800 @@ -241,6 +241,7 @@ return x; error: + x->km.state = XFRM_STATE_DEAD; xfrm_state_put(x); error_no_put: *errp = err; From krkumar@us.ibm.com Tue Jan 13 13:34:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 13:35:00 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DLYl6H032253 for ; Tue, 13 Jan 2004 13:34:47 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0DLYf9n634994; Tue, 13 Jan 2004 16:34:41 -0500 Received: from linux-udp15191261uds.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0DLYe9I039136; Tue, 13 Jan 2004 16:34:40 -0500 Date: Tue, 13 Jan 2004 13:26:21 -0800 (PST) From: Krishna Kumar X-X-Sender: krkumar@linux-udp14999547uds To: "David S. Miller" cc: netdev@oss.sgi.com, KK Subject: [PATCH 5/5] schedule() bug in xfrm_lookup() In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2403 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1252 Lines: 42 When xfrm_tmpl_resolve fails, schedule() before retrying. Also, cleaned up the set_task_* routines to use set_current_*, etc. This needs to be applied after [PATCH 3/5]. thanks, - KK diff -ruN linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_policy.c linux-2.6.0-rc2-bk6/net/xfrm/xfrm_policy.c --- linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_policy.c 2004-01-09 12:42:53.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/xfrm/xfrm_policy.c 2004-01-12 09:55:26.000000000 -0800 @@ -775,20 +775,17 @@ if (unlikely(nx<0)) { err = nx; - if (err == -EAGAIN) { - struct task_struct *tsk = current; - DECLARE_WAITQUEUE(wait, tsk); - if (!flags) - goto error; + if (err == -EAGAIN && !flags) { + DECLARE_WAITQUEUE(wait, current); - __set_task_state(tsk, TASK_INTERRUPTIBLE); add_wait_queue(&km_waitq, &wait); - nx = xfrm_tmpl_resolve(policy, fl, xfrm, family); - if (nx == -EAGAIN) - schedule(); - __set_task_state(tsk, TASK_RUNNING); + set_current_state(TASK_INTERRUPTIBLE); + schedule(); + set_current_state(TASK_RUNNING); remove_wait_queue(&km_waitq, &wait); + nx = xfrm_tmpl_resolve(policy, fl, xfrm, family); + if (nx == -EAGAIN && signal_pending(current)) { err = -ERESTART; goto error; From shemminger@osdl.org Tue Jan 13 14:23:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 14:23:22 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DMN76H001465 for ; Tue, 13 Jan 2004 14:23:08 -0800 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 i0DMM4o20847; Tue, 13 Jan 2004 14:22:04 -0800 Date: Tue, 13 Jan 2004 14:22:04 -0800 From: Stephen Hemminger To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, Jeff Garzik , "David S. Miller" , netdev@oss.sgi.com, Linux kernel mailing list Subject: [PATCH 2.6.X] SIOCSIFNAME wilcard suppor & name validation Message-Id: <20040113142204.0b41403b.shemminger@osdl.org> In-Reply-To: <20040112234332.GA1785@bougret.hpl.hp.com> References: <20040112234332.GA1785@bougret.hpl.hp.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (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: 2404 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 Content-Length: 2902 Lines: 124 Here is an enhanced version of the previous patch. It adds both the wildcard support that Jean did, and validation of network device names. It doesn't check the error return from class_device_rename because that will not fail unless object or name are null. diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Tue Jan 13 14:20:51 2004 +++ b/net/core/dev.c Tue Jan 13 14:20:51 2004 @@ -621,6 +621,21 @@ } /** + * dev_valid_name - check if name is okay for network device + * @name: name string + * + * Network device names need to be valid file names to + * to allow sysfs to work + */ +int dev_valid_name(const char *name) +{ + return !(*name == '\0' + || !strcmp(name, ".") + || !strcmp(name, "..") + || strchr(name, '/')); +} + +/** * dev_alloc_name - allocate a name for a device * @dev: device * @name: name format string @@ -660,6 +675,41 @@ return -ENFILE; /* Over 100 of the things .. bail out! */ } + +/** + * dev_change_name - change name of a device + * @dev: device + * @name: name (or format string) must be at least IFNAMSIZ + * + * Change name of a device, can pass format strings "eth%d". + * for wildcarding. + */ +int dev_change_name(struct net_device *dev, char *newname) +{ + ASSERT_RTNL(); + + if (dev->flags & IFF_UP) + return -EBUSY; + + if (!dev_valid_name(newname)) + return -EINVAL; + + if (strchr(newname, '%')) { + int err = dev_alloc_name(dev, newname); + if (err) + return err; + strcpy(newname, dev->name); + } + else if (__dev_get_by_name(newname)) + return -EEXIST; + else + strlcpy(dev->name, newname, IFNAMSIZ); + + class_device_rename(&dev->class_dev, dev->name); + notifier_call_chain(&netdev_chain, NETDEV_CHANGENAME, dev); + return 0; +} + /** * dev_alloc - allocate a network device and name * @name: name format string @@ -2359,20 +2409,8 @@ return 0; case SIOCSIFNAME: - if (dev->flags & IFF_UP) - return -EBUSY; ifr->ifr_newname[IFNAMSIZ-1] = '\0'; - if (__dev_get_by_name(ifr->ifr_newname)) - return -EEXIST; - err = class_device_rename(&dev->class_dev, - ifr->ifr_newname); - if (!err) { - strlcpy(dev->name, ifr->ifr_newname, IFNAMSIZ); - - notifier_call_chain(&netdev_chain, - NETDEV_CHANGENAME, dev); - } - return err; + return dev_change_name(dev, ifr->ifr_newname); /* * Unknown or private ioctl @@ -2505,6 +2543,7 @@ */ case SIOCGMIIPHY: case SIOCGMIIREG: + case SIOCSIFNAME: if (!capable(CAP_NET_ADMIN)) return -EPERM; dev_load(ifr.ifr_name); @@ -2536,7 +2575,6 @@ case SIOCDELMULTI: case SIOCSIFHWBROADCAST: case SIOCSIFTXQLEN: - case SIOCSIFNAME: case SIOCSMIIREG: case SIOCBONDENSLAVE: case SIOCBONDRELEASE: @@ -2685,6 +2723,11 @@ ret = -EIO; goto out_err; } + } + + if (!dev_valid_name(dev->name)) { + ret = -EINVAL; + goto out_err; } dev->ifindex = dev_new_index(); From ganachar@usc.edu Tue Jan 13 14:52:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 14:52:27 -0800 (PST) Received: from postal.usc.edu (nsmsg@postal.usc.edu [128.125.253.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DMqC6H002714 for ; Tue, 13 Jan 2004 14:52:12 -0800 Received: from usc.edu (localhost.usc.edu [127.0.0.1]) by postal.usc.edu (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HRG00E009KIA1@postal.usc.edu> for netdev@oss.sgi.com; Tue, 13 Jan 2004 14:38:42 -0800 (PST) Received: from [66.229.166.54] by postal.usc.edu (mshttpd); Tue, 13 Jan 2004 14:38:42 -0800 Date: Tue, 13 Jan 2004 14:38:42 -0800 From: tanmay ganacharya Subject: Units of the value in t_rtttime and t_rxtcur To: netdev@oss.sgi.com Message-id: <837c3083b839.83b839837c30@usc.edu> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.21 (built Sep 8 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-archive-position: 2405 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganachar@usc.edu Precedence: bulk X-list: netdev Content-Length: 774 Lines: 16 Hello, I am working on a project in which I need to find the instantaneous RTT's and RTO's over a period of 20 Minutes of a TCP connection. I was able to get the RTT and RTO values from the t_rtttime and t_rxtcur variables in the tcp block structure but am not able to figure out the units of the values. I need to get both in same units. I think RTO's are in ticks. But am not very sure about RTT. Please could you help me with the same. I would really be grateful. Also I found that 1 TCP tick = 224 miliseconds. I just wanted to confim whether it is correct. I am using FreeBSD 4.9 Stable. I am sending a sample of the values I have collected. t_rtttime = 354397342, t_srtt = 68069, t_rxtcur = 1689 Waiting for your reply. Thanking you, Yours truly, Tanmay Ganacharya From jt@bougret.hpl.hp.com Tue Jan 13 14:54:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 14:54:41 -0800 (PST) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DMsI6H003111 for ; Tue, 13 Jan 2004 14:54:18 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id F36481C0042F; Tue, 13 Jan 2004 14:27:45 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id OAA07484; Tue, 13 Jan 2004 14:27:45 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1AgX0j-0003AI-00; Tue, 13 Jan 2004 14:27:45 -0800 Date: Tue, 13 Jan 2004 14:27:45 -0800 To: Stephen Hemminger Cc: Jeff Garzik , "David S. Miller" , netdev@oss.sgi.com, Linux kernel mailing list Subject: Re: [PATCH 2.6.X] SIOCSIFNAME wilcard suppor & name validation Message-ID: <20040113222745.GA12147@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040112234332.GA1785@bougret.hpl.hp.com> <20040113142204.0b41403b.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040113142204.0b41403b.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: 2406 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 Content-Length: 447 Lines: 15 On Tue, Jan 13, 2004 at 02:22:04PM -0800, Stephen Hemminger wrote: > Here is an enhanced version of the previous patch. > It adds both the wildcard support that Jean did, and validation of network > device names. Excellent. Your patch looks much cleaner. > It doesn't check the error return from class_device_rename because > that will not fail unless object or name are null. I was not 100% sure if this would remain true. Thanks ! Jean From romieu@fr.zoreil.com Tue Jan 13 15:04:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 15:05:12 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DN4v6H004137 for ; Tue, 13 Jan 2004 15:04:58 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0DN4TsW024379; Wed, 14 Jan 2004 00:04:29 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0DN4Rsb024378; Wed, 14 Jan 2004 00:04:27 +0100 Date: Wed, 14 Jan 2004 00:04:27 +0100 From: Francois Romieu To: netdev@oss.sgi.com Cc: dpollock@acm.org, damouse@ntlworld.com, brad@mainstreetsoftworks.com, kinetik@orcon.net.nz Subject: Re: Realtek 8169 Lock-ups Message-ID: <20040114000427.A21899@electric-eye.fr.zoreil.com> References: <1073507006.5151.61.camel@localhost> <20040107232034.A22930@electric-eye.fr.zoreil.com> <1073596694.6378.6.camel@localhost> <4001080D.3090401@pobox.com> <20040111124957.A18068@electric-eye.fr.zoreil.com> <20040113000357.D5983@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040113000357.D5983@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Tue, Jan 13, 2004 at 12:03:57AM +0100 X-Organisation: Land of Sunshine Inc. X-archive-position: 2407 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 270 Lines: 11 Re, latest pile of r8169 related patches against 2.6.1-bk1 available at: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.1-bk1-a Credits go to damouse@ntlworld.com for a bug removal in r8169-init_one.patch. No change of behavior expected for SMP so far. -- Ueimor From davem@pizda.ninka.net Tue Jan 13 15:08:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 15:08:55 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DN8g6H004608 for ; Tue, 13 Jan 2004 15:08:42 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id PAA09224; Tue, 13 Jan 2004 15:01:44 -0800 Date: Tue, 13 Jan 2004 15:01:44 -0800 From: "David S. Miller" To: Andi Kleen Cc: ak@muc.de, netdev@oss.sgi.com Subject: Re: [PATCH] Mark SIOCSIFNAME as compatible ioctl Message-Id: <20040113150144.1f8e214c.davem@redhat.com> In-Reply-To: <20040109165627.2e0845af.ak@suse.de> References: <20040108070413.GA31778@averell> <20040109020456.045b447e.davem@redhat.com> <20040109165627.2e0845af.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2408 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: 388 Lines: 14 On Fri, 9 Jan 2004 16:56:27 +0100 Andi Kleen wrote: > On Fri, 9 Jan 2004 02:04:56 -0800 > "David S. Miller" wrote: > > > How can we mark it compatible? It needs the stuff dev_ifname32() in > > fs/compat_ioctl.c does for SIOCGIFNAME doesn't it? > > It takes two strings. This should be compatible: You're absolutely right Andi, thanks. Patch applied. From jgarzik@pobox.com Tue Jan 13 15:16:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 15:17:10 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DNGs6H005109 for ; Tue, 13 Jan 2004 15:16:55 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:37039 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AgXmH-0005sv-Mp; Tue, 13 Jan 2004 23:16:53 +0000 Message-ID: <40047C5A.3090604@pobox.com> Date: Tue, 13 Jan 2004 18:16:42 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton , Netdev Subject: netdev4 posted Content-Type: multipart/mixed; boundary="------------060909000208080600020605" X-archive-position: 2409 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 Content-Length: 3055 Lines: 76 This is a multi-part message in MIME format. --------------060909000208080600020605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Key e100 fix, that possibly wants fixing in eepro100 too. Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev4.patch.bz2 Full changelog: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev4.log Broken out: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/broken-out/ Changelog delta attached. --------------060909000208080600020605 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="changelog.txt" ChangeSet@1.1510.9.19, 2004-01-13 16:43:24-05:00, romieu@fr.zoreil.com [netdrvr r8169] fix phy initialization loop init ChangeSet@1.1510.8.7, 2004-01-13 15:30:03-05:00, scott.feldman@intel.com [netdrvr e100] copyright + trailing blanks + misc * Misc: 2004 copyright, remove trailing white space, remove some unused symbols. ChangeSet@1.1510.8.6, 2004-01-13 15:29:55-05:00, scott.feldman@intel.com [netdrvr e100] fix slab corruption * Addresses two problems, both resulting in slab corruption: 1) driver indicating skb while HW is still DMA'ing (ouch!), 2) driver not stopping receiver activity before downing i/f. Fix is 1) wait for RNR (receiver-no-resources) interrupt before restarting receiver, 2) reseting HW to stop receiver before stopping i/f. This issue was also reproducible with eepro100. You need to turn off the copybreak, and reduce the number of descriptors to 4. Then bang on it with pktgen with 60-byte packets, with slab debugging enabled. For e100-3.0.x, the issue was a lot easier to reproduce with NAPI, because NAPI polls independently of where the HW is at, so it's easier for us to catch HW in the middle of finishing off the last Rx (as it runs out of resources) and asking HW if it's idle. Checking the RU status is not-reliable! That's the problem, and the mistake both eepro100 and e100-3.0.x were making. The solution is rely on RNR interrupts as the only indicator that HW is truly done, and then we're ready to restart the RU. We should only get RNR interrupts when we overrun the Rx ring. With NAPI, if the ring is overrun, we'll post RNR, but not restart the RU until we're out of polling. Without NAPI, we'll restart the RU as soon as we get RNR. I ran some 24-hour tests with and without NAPI (with 4 descriptors) and didn't get any corruption. Prior to this patch, I would get many errors about slab corruption. Also, the patch is larger than you might expect, but I initially thought I was doing something wrong with managing the ring, so I that code using old fashion double-link list. The ring management wasn't the problem, after all, but I prefer the old-fashion d-link implementation as it's easier to read. --------------060909000208080600020605-- From shemminger@osdl.org Tue Jan 13 15:46:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 15:46:37 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DNkL6H006088 for ; Tue, 13 Jan 2004 15:46:24 -0800 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 i0DNkAo04755; Tue, 13 Jan 2004 15:46:10 -0800 Date: Tue, 13 Jan 2004 15:46:10 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] support for large number of network devices. Message-Id: <20040113154610.38f5934c.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (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: 2410 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 Content-Length: 1887 Lines: 68 When using pseudo network devices, and really big machines; there is sometimes a need to have a lot of network devices. This replaces the existing 2.6.1 limit of 100 entries an was O(n^2) with a algorithm that will handle up to 32768 entries with O(n) behaviour. Does need a temporary page, but that shouldn't be a big deal. It has the same semantics, it will find the first empty name and use it. diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Tue Jan 13 15:42:19 2004 +++ b/net/core/dev.c Tue Jan 13 15:42:19 2004 @@ -650,8 +650,11 @@ int dev_alloc_name(struct net_device *dev, const char *name) { int i; - char buf[32]; char *p; + const int max_netdevices = 8*PAGE_SIZE; + long *inuse; + struct net_device *d; + char buf[IFNAMSIZ]; /* * Verify the string as this thing may have come from @@ -662,17 +665,34 @@ if (p && (p[1] != 'd' || strchr(p + 2, '%'))) return -EINVAL; - /* - * If you need over 100 please also fix the algorithm... - */ - for (i = 0; i < 100; i++) { - snprintf(buf, sizeof(buf), name, i); - if (!__dev_get_by_name(buf)) { - strcpy(dev->name, buf); - return i; + /* Use one page as a bit array of possible slots */ + inuse = (long *) get_zeroed_page(GFP_ATOMIC); + if (!inuse) + return -ENOMEM; + + for (d = dev_base; d; d = d->next) { + if (sscanf(d->name, name, &i)) { + if (i < 0 || i >= max_netdevices) + continue; + + set_bit(i, inuse); } } - return -ENFILE; /* Over 100 of the things .. bail out! */ + + i = find_first_zero_bit(inuse, max_netdevices); + free_page((unsigned long) inuse); + snprintf(buf, sizeof(buf), name, i); + + if (!__dev_get_by_name(buf)) { + strcpy(dev->name, buf); + return i; + } + + /* It is possible to run out of possible slots + * when the name is long and there isn't enough space left + * for the digits, or if all bits are used. + */ + return -ENFILE; } From romieu@fr.zoreil.com Tue Jan 13 16:01:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:01:29 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E01D6H007265 for ; Tue, 13 Jan 2004 16:01:16 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0DNvdsW025291; Wed, 14 Jan 2004 00:57:39 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0DNvc2T025290; Wed, 14 Jan 2004 00:57:38 +0100 Date: Wed, 14 Jan 2004 00:57:38 +0100 From: Francois Romieu To: dpollock@acm.org Cc: netdev@oss.sgi.com Subject: Re: Realtek 8169 Lock-ups Message-ID: <20040114005738.B21899@electric-eye.fr.zoreil.com> References: <1073507006.5151.61.camel@localhost> <20040107232034.A22930@electric-eye.fr.zoreil.com> <1073596694.6378.6.camel@localhost> <4001080D.3090401@pobox.com> <20040111124957.A18068@electric-eye.fr.zoreil.com> <20040113000357.D5983@electric-eye.fr.zoreil.com> <1074020596.5336.0.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1074020596.5336.0.camel@localhost>; from pollockd@magma.ca on Tue, Jan 13, 2004 at 02:03:16PM -0500 X-Organisation: Land of Sunshine Inc. X-archive-position: 2411 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 565 Lines: 18 pollockd@magma.ca : [...] > With SMP enabled, I get the following, and the packet generator aborts > quickly: > > APIC error on CPU0: 40(40) > eth0: Too much work at interrupt! > eth0: Too much work at interrupt! Well, it is not clear that the "Too muck work at interrupt" recovery logic really recovers much (be it for vanilla or modified r8169 driver). Does it behave differently if you make the "while (boguscnt > 0);" always true in rtl8169_interrupt() and ask for a finite number of packets (say pgset "count 1000" or more) ? -- Ueimor From davem@pizda.ninka.net Tue Jan 13 16:06:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:06:32 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E06I6H007719 for ; Tue, 13 Jan 2004 16:06:18 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id PAA09379; Tue, 13 Jan 2004 15:59:21 -0800 Date: Tue, 13 Jan 2004 15:59:21 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-Id: <20040113155921.342db463.davem@redhat.com> In-Reply-To: <20040113154610.38f5934c.shemminger@osdl.org> References: <20040113154610.38f5934c.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2412 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: 810 Lines: 18 On Tue, 13 Jan 2004 15:46:10 -0800 Stephen Hemminger wrote: > When using pseudo network devices, and really big machines; there is > sometimes a need to have a lot of network devices. This replaces the > existing 2.6.1 limit of 100 entries an was O(n^2) > with a algorithm that will handle up to 32768 entries with O(n) behaviour. > > Does need a temporary page, but that shouldn't be a big deal. > It has the same semantics, it will find the first empty name and use it. I think your code has different semantics than exist currently. For example, let's use the example of asking for "slip%d" then "eth%d". The existing code would hand out "slip0" then "eth0", but your code would deliver "slip0" then "eth1" which is not correct. Or did I miss something clever in your algorithm? From davem@pizda.ninka.net Tue Jan 13 16:08:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:08:44 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E08V6H008115 for ; Tue, 13 Jan 2004 16:08:31 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA09396; Tue, 13 Jan 2004 16:01:35 -0800 Date: Tue, 13 Jan 2004 16:01:35 -0800 From: "David S. Miller" To: Nathaniel M Nelson Cc: netdev@oss.sgi.com Subject: Re: Possible weird TCP bug Message-Id: <20040113160135.45cc677d.davem@redhat.com> In-Reply-To: <3FFE2B00.2030607@chartermi.net> References: <3FFE2B00.2030607@chartermi.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2413 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: 1415 Lines: 27 On Thu, 08 Jan 2004 23:16:00 -0500 Nathaniel M Nelson wrote: > 0000 00 02 7d 66 a4 54 00 e0 81 23 14 78 08 00 45 00 ..}f.T.. .#.x..E. > 0010 00 3c 9a 41 40 00 3f 06 f4 1f 18 e7 92 21 d8 ef .<.A@.?. .....!.. > 0020 29 63 89 37 00 50 e5 4b 22 e0 00 00 00 00 a0 02 )c.7.P.K "....... > 0030 16 d0 36 6a 00 00 02 04 05 b4 04 02 08 0a 03 1d ..6j.... ........ > 0040 b8 a1 00 00 00 00 01 03 03 00 ........ .. > > Then after I get the SYN,ACK back, the firewall will send out the next > ACK with the sequence number correctly incremented by 1. > > 0000 00 02 7d 66 a4 54 00 e0 81 23 14 78 08 00 45 00 ..}f.T.. .#.x..E. > 0010 00 28 9a 42 40 00 3f 06 f4 32 18 e7 92 21 d8 ef .(.B@.?. .2...!.. > 0020 29 63 89 37 00 50 e5 4b 22 e1 db f2 5c c5 50 10 )c.7.P.K "...\.P. > 0030 16 d0 21 3d 00 00 ..!=. > > So of course the sequence is "1" in that packet. Both sequence numbers > seem a little low though... and not very cryptic. If this is not a bug > I apoligize in advance. In the initial packet, the only zero is the "ACK" sequence, when the first SYN goes out we don't know the starting sequence number the other side will decide to use so we set that field to zero (and also the ACK bit is clear in this packet which makes the ACK sequence field not valid anyways). This dump looks perfectly fine to me. From shemminger@osdl.org Tue Jan 13 16:13:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:13:28 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0DF6H008573 for ; Tue, 13 Jan 2004 16:13:15 -0800 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 i0E0D3o10536; Tue, 13 Jan 2004 16:13:03 -0800 Date: Tue, 13 Jan 2004 16:13:03 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-Id: <20040113161303.20f1159d.shemminger@osdl.org> In-Reply-To: <20040113155921.342db463.davem@redhat.com> References: <20040113154610.38f5934c.shemminger@osdl.org> <20040113155921.342db463.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (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: 2414 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 Content-Length: 1090 Lines: 25 On Tue, 13 Jan 2004 15:59:21 -0800 "David S. Miller" wrote: > On Tue, 13 Jan 2004 15:46:10 -0800 > Stephen Hemminger wrote: > > > When using pseudo network devices, and really big machines; there is > > sometimes a need to have a lot of network devices. This replaces the > > existing 2.6.1 limit of 100 entries an was O(n^2) > > with a algorithm that will handle up to 32768 entries with O(n) behaviour. > > > > Does need a temporary page, but that shouldn't be a big deal. > > It has the same semantics, it will find the first empty name and use it. > > I think your code has different semantics than exist currently. > > For example, let's use the example of asking for "slip%d" then "eth%d". > The existing code would hand out "slip0" then "eth0", but your code would > deliver "slip0" then "eth1" which is not correct. > > Or did I miss something clever in your algorithm? It uses the output format string for the sscanf match, and since sscanf formats have to match. sscanf("eth0", "slip%d", &i) returns 0 so eth0 would be skipped From davem@pizda.ninka.net Tue Jan 13 16:22:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:22:25 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0MC6H012091 for ; Tue, 13 Jan 2004 16:22:12 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA09475; Tue, 13 Jan 2004 16:15:15 -0800 Date: Tue, 13 Jan 2004 16:15:15 -0800 From: "David S. Miller" To: David Stevens Cc: hibi665@oki.com, netdev@oss.sgi.com Subject: Re: MLD problems (again) [PATCH] Message-Id: <20040113161515.0bff155e.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2415 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: 538 Lines: 13 On Sun, 11 Jan 2004 22:49:08 -0700 David Stevens wrote: > Although IGMPv3 didn't have any problems, this patch > also re-arranges the order of the filter changes. I think it's cleaner > to add the new one first and then delete the old one, rather than > having a small window with no filter set. So, this is a bug fix for MLD > and a code clean-up for IGMPv3. > This bug and patch should also apply to the 2.4 line. Applied, thank you David. Also, arigato Takashi-san for the bug report and testing. From greearb@candelatech.com Tue Jan 13 16:23:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:23:50 -0800 (PST) Received: from ns1.wanfear.com (ns1.wanfear.com [207.212.57.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0Nb6H012473 for ; Tue, 13 Jan 2004 16:23:37 -0800 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by ns1.wanfear.com (8.12.10/8.12.8) with ESMTP id i0E0NP9v022436; Tue, 13 Jan 2004 16:23:25 -0800 Message-ID: <40048BFD.4010303@candelatech.com> Date: Tue, 13 Jan 2004 16:23:25 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. References: <20040113154610.38f5934c.shemminger@osdl.org> In-Reply-To: <20040113154610.38f5934c.shemminger@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2416 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 Content-Length: 628 Lines: 18 Stephen Hemminger wrote: > When using pseudo network devices, and really big machines; there is > sometimes a need to have a lot of network devices. This replaces the > existing 2.6.1 limit of 100 entries an was O(n^2) > with a algorithm that will handle up to 32768 entries with O(n) behaviour. Might be a good time to put in hash tables to find network devices by name and by device-id. There are a few parts of the networking stack that do lookups, and walking the device list when it's 4k entries long takes a while... Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From scott.feldman@intel.com Tue Jan 13 16:25:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:25:43 -0800 (PST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0PU6H012869 for ; Tue, 13 Jan 2004 16:25:30 -0800 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0E0Pm1g017048; Wed, 14 Jan 2004 00:25:48 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0E0KeSo019429; Wed, 14 Jan 2004 00:21:00 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011316232813537 ; Tue, 13 Jan 2004 16:23:28 -0800 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 13 Jan 2004 16:23:28 -0800 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: [PATCH] make tg3 NAPI support configurable Date: Tue, 13 Jan 2004 16:23:27 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] make tg3 NAPI support configurable Thread-Index: AcPaCQLBGAMgflYFToKkT6HVZbQ6NgAK2AtQ From: "Feldman, Scott" To: "Robert Olsson" , "Jeff Garzik" Cc: "Greg Banks" , "David S. Miller" , "Linux Network Development list" , X-OriginalArrivalTime: 14 Jan 2004 00:23:28.0052 (UTC) FILETIME=[A1946F40:01C3DA34] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0E0PU6H012869 X-archive-position: 2417 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 Content-Length: 996 Lines: 32 > I was thinking of a variant JC [jchapman@katalix.com] > mentioned on this list some time ago. He also sent me > the patch for e1000. A test and the patch is below. JC contributed almost the exact patch for the e100 rewrite and it did help Tx, but I don't remember how much. JC, do you remember? Here is the snippet: static int e100_poll(struct net_device *netdev, int *budget) { struct nic *nic = netdev->priv; unsigned int work_to_do = min(netdev->quota, *budget); unsigned int work_done = 0; int tx_cleaned; e100_rx_clean(nic, &work_done, work_to_do); tx_cleaned = e100_tx_clean(nic); /* If no Rx and Tx cleanup work was done, exit polling mode. */ if((!tx_cleaned && (work_done == 0)) || !netif_running(netdev)) { netif_rx_complete(netdev); e100_enable_irq(nic); return 0; } *budget -= work_done; netdev->quota -= work_done; return 1; } From davem@pizda.ninka.net Tue Jan 13 16:25:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:26:12 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0Px6H013024 for ; Tue, 13 Jan 2004 16:25:59 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA09552; Tue, 13 Jan 2004 16:19:03 -0800 Date: Tue, 13 Jan 2004 16:19:03 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] bridge use read_lock when scanning device list Message-Id: <20040113161903.5eaf893a.davem@redhat.com> In-Reply-To: <20040112134645.461f125e.shemminger@osdl.org> References: <20040112134645.461f125e.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2418 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: 245 Lines: 7 On Mon, 12 Jan 2004 13:46:45 -0800 Stephen Hemminger wrote: > On 2.6.1, bridge is using rtnl_shlock which is equivalent to rtnl_lock when > all it really needs to do is read_lock(&dev_base_lock). Applied, thanks Stephen. From davem@pizda.ninka.net Tue Jan 13 16:26:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:27:07 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0Qs6H013604 for ; Tue, 13 Jan 2004 16:26:54 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA09574; Tue, 13 Jan 2004 16:19:58 -0800 Date: Tue, 13 Jan 2004 16:19:58 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] convert /proc/net/dev_mcast to seq_file Message-Id: <20040113161958.5e05c655.davem@redhat.com> In-Reply-To: <20040112135033.3b08f0e9.shemminger@osdl.org> References: <20040112135033.3b08f0e9.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2419 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: 196 Lines: 6 On Mon, 12 Jan 2004 13:50:33 -0800 Stephen Hemminger wrote: > Convert /proc/net/dev_mcast for 2.6 so it will work with large number of interfaces. Applied, thanks Stephen. From davem@pizda.ninka.net Tue Jan 13 16:28:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:28:22 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0S96H013987 for ; Tue, 13 Jan 2004 16:28:09 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA09618; Tue, 13 Jan 2004 16:21:12 -0800 Date: Tue, 13 Jan 2004 16:21:12 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: jt@hpl.hp.com, jt@bougret.hpl.hp.com, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2.6.X] SIOCSIFNAME wilcard suppor & name validation Message-Id: <20040113162112.509edb71.davem@redhat.com> In-Reply-To: <20040113142204.0b41403b.shemminger@osdl.org> References: <20040112234332.GA1785@bougret.hpl.hp.com> <20040113142204.0b41403b.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2420 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: 416 Lines: 13 On Tue, 13 Jan 2004 14:22:04 -0800 Stephen Hemminger wrote: > Here is an enhanced version of the previous patch. > It adds both the wildcard support that Jean did, and validation of network > device names. > > It doesn't check the error return from class_device_rename because > that will not fail unless object or name are null. This is really cool, nice work guys. Patch applied, thanks. From davem@pizda.ninka.net Tue Jan 13 16:32:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:32:34 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0WL6H014418 for ; Tue, 13 Jan 2004 16:32:22 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA09700; Tue, 13 Jan 2004 16:25:18 -0800 Date: Tue, 13 Jan 2004 16:25:18 -0800 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com, jorge@dti2.net Subject: Re: [PATCH][ATM]: [nicstar] convert to new style pci module (by "Jorge Boncompte [DTI2]" ) Message-Id: <20040113162518.458e817d.davem@redhat.com> In-Reply-To: <200401130503.i0D53nRr019754@ginger.cmf.nrl.navy.mil> References: <200401130503.i0D53nRr019754@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2421 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: 166 Lines: 7 On Tue, 13 Jan 2004 00:03:50 -0500 chas williams (contractor) wrote: > please apply to 2.4 > please apply to 2.6 Both applied, thanks Chas. From shemminger@osdl.org Tue Jan 13 16:38:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:38:47 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0cY6H015311 for ; Tue, 13 Jan 2004 16:38:34 -0800 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 i0E0cSo16295; Tue, 13 Jan 2004 16:38:28 -0800 Date: Tue, 13 Jan 2004 16:38:28 -0800 From: Stephen Hemminger To: Ben Greear Cc: netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-Id: <20040113163828.64ec4743.shemminger@osdl.org> In-Reply-To: <40048BFD.4010303@candelatech.com> References: <20040113154610.38f5934c.shemminger@osdl.org> <40048BFD.4010303@candelatech.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (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: 2422 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 Content-Length: 816 Lines: 17 On Tue, 13 Jan 2004 16:23:25 -0800 Ben Greear wrote: > Stephen Hemminger wrote: > > When using pseudo network devices, and really big machines; there is > > sometimes a need to have a lot of network devices. This replaces the > > existing 2.6.1 limit of 100 entries an was O(n^2) > > with a algorithm that will handle up to 32768 entries with O(n) behaviour. > > Might be a good time to put in hash tables to find network devices by > name and by device-id. There are a few parts of the networking stack > that do lookups, and walking the device list when it's 4k entries > long takes a while... I have a patch for name hashing, but don't know if it's needed. Even without it I can add 9 thousand bridge entries, and each one takes longer to start the command than add the entry now. From davem@pizda.ninka.net Tue Jan 13 16:43:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:43:41 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0hS6H015784 for ; Tue, 13 Jan 2004 16:43:28 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA09833; Tue, 13 Jan 2004 16:36:32 -0800 Date: Tue, 13 Jan 2004 16:36:31 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] (1/5) replay netdev notifier events on registration Message-Id: <20040113163631.1a9c1a59.davem@redhat.com> In-Reply-To: <20040113105843.0d1351cb.shemminger@osdl.org> References: <20040113105843.0d1351cb.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2423 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: 998 Lines: 22 On Tue, 13 Jan 2004 10:58:43 -0800 Stephen Hemminger wrote: > Several protocols register for network device notification to detect new new network devices; > but then have to walk the device list to capture the devices that are already up. > This leaves a exposed window between when the notifier is registered and when the list walk > occurs. Also, in several cases, there is a different code path for the pre-existing and > new devices which leads to bug exposure. > > The solution is to replay the registration and up events for existing devices into the > new notifier. > > All notifiers in 2.6.1 have been audited and the other patches fix places > where protocols were doing there own registered device discovery loop. > > Thanks to Al Viro for the suggestion. Looks good.... are you absolutely sure no remaining notifiers will barf if they get a register for an already existing device? I know up events should be ok... Anyways, I applied all 5 patches, thanks. From greearb@candelatech.com Tue Jan 13 17:55:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 17:55:49 -0800 (PST) Received: from ns1.wanfear.com (ns1.wanfear.com [207.212.57.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E1tY6H018116 for ; Tue, 13 Jan 2004 17:55:36 -0800 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by ns1.wanfear.com (8.12.10/8.12.8) with ESMTP id i0E1tW9v025145; Tue, 13 Jan 2004 17:55:32 -0800 Message-ID: <4004A194.3030602@candelatech.com> Date: Tue, 13 Jan 2004 17:55:32 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger , "'netdev@oss.sgi.com'" Subject: Re: [PATCH] support for large number of network devices. References: <20040113154610.38f5934c.shemminger@osdl.org> <40048BFD.4010303@candelatech.com> <20040113163828.64ec4743.shemminger@osdl.org> In-Reply-To: <20040113163828.64ec4743.shemminger@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2424 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 Content-Length: 1332 Lines: 37 Stephen Hemminger wrote: > On Tue, 13 Jan 2004 16:23:25 -0800 > Ben Greear wrote: > > >>Stephen Hemminger wrote: >> >>>When using pseudo network devices, and really big machines; there is >>>sometimes a need to have a lot of network devices. This replaces the >>>existing 2.6.1 limit of 100 entries an was O(n^2) >>>with a algorithm that will handle up to 32768 entries with O(n) behaviour. >> >>Might be a good time to put in hash tables to find network devices by >>name and by device-id. There are a few parts of the networking stack >>that do lookups, and walking the device list when it's 4k entries >>long takes a while... > > > I have a patch for name hashing, but don't know if it's needed. > Even without it I can add 9 thousand bridge entries, > and each one takes longer to start the command than add the entry now. Check out the af_packet code. At least some branches do a device lookup by name for each transmitted packet. One method is: packet_sendmsg_spkt packet_sendmsg gets by index, which could also be hashed... At one time ifconfig -a was almost un-usable with large numbers of devices, but I think it has been improved. I haven't tried on large numbers of devices lately... -- Ben Greear Candela Technologies Inc http://www.candelatech.com From oxymoron@waste.org Tue Jan 13 23:13:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 23:13:35 -0800 (PST) Received: from waste.org (waste.org [209.173.204.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E7DJ6H029665 for ; Tue, 13 Jan 2004 23:13:19 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0E7DBhm031020; Wed, 14 Jan 2004 01:13:11 -0600 Received: (from oxymoron@localhost) by waste.org (8.12.3/8.12.3/Debian-6.6) id i0E7D31e031018; Wed, 14 Jan 2004 01:13:03 -0600 Date: Wed, 14 Jan 2004 01:13:03 -0600 From: Matt Mackall To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-ID: <20040114071303.GG28521@waste.org> References: <20040113154610.38f5934c.shemminger@osdl.org> <20040113155921.342db463.davem@redhat.com> <20040113161303.20f1159d.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040113161303.20f1159d.shemminger@osdl.org> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new X-archive-position: 2425 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 Content-Length: 1399 Lines: 32 On Tue, Jan 13, 2004 at 04:13:03PM -0800, Stephen Hemminger wrote: > On Tue, 13 Jan 2004 15:59:21 -0800 > "David S. Miller" wrote: > > > On Tue, 13 Jan 2004 15:46:10 -0800 > > Stephen Hemminger wrote: > > > > > When using pseudo network devices, and really big machines; there is > > > sometimes a need to have a lot of network devices. This replaces the > > > existing 2.6.1 limit of 100 entries an was O(n^2) > > > with a algorithm that will handle up to 32768 entries with O(n) behaviour. > > > > > > Does need a temporary page, but that shouldn't be a big deal. > > > It has the same semantics, it will find the first empty name and use it. > > > > I think your code has different semantics than exist currently. > > > > For example, let's use the example of asking for "slip%d" then "eth%d". > > The existing code would hand out "slip0" then "eth0", but your code would > > deliver "slip0" then "eth1" which is not correct. > > > > Or did I miss something clever in your algorithm? > > It uses the output format string for the sscanf match, and since > sscanf formats have to match. sscanf("eth0", "slip%d", &i) returns 0 > so eth0 would be skipped Unfortunately sscanf("eth0-not-allocated", "eth%d", &i) fools it. Which may or may not be worth worrying about. -- Matt Mackall : http://www.selenic.com : Linux development and consulting From davem@pizda.ninka.net Tue Jan 13 23:25:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 23:25:40 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E7PR6H030452 for ; Tue, 13 Jan 2004 23:25:27 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA10430; Tue, 13 Jan 2004 23:18:25 -0800 Date: Tue, 13 Jan 2004 23:18:25 -0800 From: "David S. Miller" To: Ben Greear Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-Id: <20040113231825.700e534f.davem@redhat.com> In-Reply-To: <4004A194.3030602@candelatech.com> References: <20040113154610.38f5934c.shemminger@osdl.org> <40048BFD.4010303@candelatech.com> <20040113163828.64ec4743.shemminger@osdl.org> <4004A194.3030602@candelatech.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2426 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: 1094 Lines: 26 On Tue, 13 Jan 2004 17:55:32 -0800 Ben Greear wrote: > Stephen Hemminger wrote: > > I have a patch for name hashing, but don't know if it's needed. > > Even without it I can add 9 thousand bridge entries, > > and each one takes longer to start the command than add the entry now. > > Check out the af_packet code. At least some branches do a > device lookup by name for each transmitted packet. One > method is: packet_sendmsg_spkt > > packet_sendmsg gets by index, which could also be hashed... > > At one time ifconfig -a was almost un-usable with large numbers > of devices, but I think it has been improved. I haven't tried on > large numbers of devices lately... I found some other fast-path'ish cases of dev_get_by_name(), one of which is atalk_rcv()'s handling of IP over DDP packets. I didn't even search around for __dev_get() and dev_get_by_index() cases. There are probably some more there. Therefore, I think it's wise to just do this right from the start and use a hash. Stephen can you test up and submit the netdev name hash patch you have? From davem@pizda.ninka.net Tue Jan 13 23:27:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 23:27:21 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E7R86H030837 for ; Tue, 13 Jan 2004 23:27:08 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA10471; Tue, 13 Jan 2004 23:20:09 -0800 Date: Tue, 13 Jan 2004 23:20:09 -0800 From: "David S. Miller" To: Krishna Kumar Cc: krkumar@us.ibm.com, netdev@oss.sgi.com Subject: Re: [PATCH 1/5] ipcomp_tunnel_create doesn't set tunnel state Message-Id: <20040113232009.008a57a7.davem@redhat.com> In-Reply-To: References: <20040110121134.08481951.davem@redhat.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2427 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: 362 Lines: 9 On Tue, 13 Jan 2004 13:21:19 -0800 (PST) Krishna Kumar wrote: > ipcomp_tunnel_create doesn't set x->km.state to XFRM_STATE_DEAD. This can lead > to the BUG_TRAP in __xfrm_state_destroy when xfrm_state_put() finds this is > the last reference. This was reported as one of the symptoms of [Bug 1754] > some time back. Patch applied, thanks. From davem@pizda.ninka.net Tue Jan 13 23:28:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 23:28:48 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E7SZ6H031215 for ; Tue, 13 Jan 2004 23:28:35 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA10497; Tue, 13 Jan 2004 23:21:37 -0800 Date: Tue, 13 Jan 2004 23:21:37 -0800 From: "David S. Miller" To: Krishna Kumar Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2/5] Bad dereference of xfrm_state in pf_key Message-Id: <20040113232137.463554c9.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2428 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: 351 Lines: 9 On Tue, 13 Jan 2004 13:22:36 -0800 (PST) Krishna Kumar wrote: > In pfkey_get(), the xfrm_state is dereferenced after it is dropped, > which could lead to dereferencing freed memory. This can also be done > by dropping the reference before the pfkey_broadcast() and in the IS_ERR > case. Obviously correct, patch applied thanks. From davem@pizda.ninka.net Tue Jan 13 23:30:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 23:30:50 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E7Ub6H031624 for ; Tue, 13 Jan 2004 23:30:37 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA10523; Tue, 13 Jan 2004 23:23:35 -0800 Date: Tue, 13 Jan 2004 23:23:35 -0800 From: "David S. Miller" To: Krishna Kumar Cc: netdev@oss.sgi.com Subject: Re: [PATCH 3/5] xfrm_lookup bugs Message-Id: <20040113232335.2236706f.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2429 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: 412 Lines: 11 On Tue, 13 Jan 2004 13:23:35 -0800 (PST) Krishna Kumar wrote: > In xfrm_lookup, a couple of bugs : > - the found or allocated xfrm_states are not passed correctly to > xfrm_bundle_create (and to the subsequent frees in case of create > failing) if the first xfrm_tmpl_resolve failed and the second one > succeeded. > - error handling is wrong. Looks fine, patch applied thanks. From davem@pizda.ninka.net Tue Jan 13 23:32:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 23:32:36 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E7WN6H032035 for ; Tue, 13 Jan 2004 23:32:23 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA10552; Tue, 13 Jan 2004 23:25:24 -0800 Date: Tue, 13 Jan 2004 23:25:24 -0800 From: "David S. Miller" To: Krishna Kumar Cc: netdev@oss.sgi.com, krkumar@us.ibm.com Subject: Re: [PATCH 4/5] xfrm_state_construct doesn't set tunnel state Message-Id: <20040113232524.6ca5b0fe.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2430 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: 420 Lines: 11 On Tue, 13 Jan 2004 13:24:23 -0800 (PST) Krishna Kumar wrote: > xfrm_state_construct doesn't set x->km.state to XFRM_STATE_DEAD. This can lead > to the BUG_TRAP in __xfrm_state_destroy when xfrm_state_put() finds this is > the last reference. This was reported as one of the symptoms of [Bug 1754] > some time back. Smells just like the nearly identical case in ipcomp :-) Patch applied, thanks. From davem@pizda.ninka.net Tue Jan 13 23:34:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 23:34:33 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E7YK6H032448 for ; Tue, 13 Jan 2004 23:34:20 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA10578; Tue, 13 Jan 2004 23:27:22 -0800 Date: Tue, 13 Jan 2004 23:27:22 -0800 From: "David S. Miller" To: Krishna Kumar Cc: netdev@oss.sgi.com, krkumar@us.ibm.com Subject: Re: [PATCH 5/5] schedule() bug in xfrm_lookup() Message-Id: <20040113232722.2c04bc03.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2431 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: 240 Lines: 7 On Tue, 13 Jan 2004 13:26:21 -0800 (PST) Krishna Kumar wrote: > When xfrm_tmpl_resolve fails, schedule() before retrying. Also, cleaned > up the set_task_* routines to use set_current_*, etc. Applied, thanks Krishna. From greearb@candelatech.com Tue Jan 13 23:54:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 23:55:12 -0800 (PST) Received: from ns1.wanfear.com (ns1.wanfear.com [207.212.57.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E7sw6H000692 for ; Tue, 13 Jan 2004 23:54:59 -0800 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by ns1.wanfear.com (8.12.10/8.12.8) with ESMTP id i0E7su9v002648; Tue, 13 Jan 2004 23:54:57 -0800 Message-ID: <4004F5D0.7040106@candelatech.com> Date: Tue, 13 Jan 2004 23:54:56 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. References: <20040113154610.38f5934c.shemminger@osdl.org> <40048BFD.4010303@candelatech.com> <20040113163828.64ec4743.shemminger@osdl.org> <4004A194.3030602@candelatech.com> <20040113231825.700e534f.davem@redhat.com> In-Reply-To: <20040113231825.700e534f.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2432 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 Content-Length: 919 Lines: 32 David S. Miller wrote: > Therefore, I think it's wise to just do this right from the start and use a hash. > Stephen can you test up and submit the netdev name hash patch you have? > In case it proves useful, here's the hash I used before. It makes some assumptions based on the fact that the last two characters of a device name are often numbers, especially when you have lots of devices. Someone did a mapping of this and found it worked well for vlans, at least. int fdl_calc_name_idx(const char* dev_name) { int tmp = 0; int i; for (i = 0; dev_name[i]; i++) { tmp += (int)(dev_name[i]); } if (i > 3) { tmp += (dev_name[i-2] * 10); /* might add a little spread to the hash */ tmp += (dev_name[i-3] * 100); /* might add a little spread to the hash */ } return (tmp % FDL_HASH_LEN); } -- Ben Greear Candela Technologies Inc http://www.candelatech.com From vnuorval@tcs.hut.fi Wed Jan 14 01:08:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 01:08:20 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E9856H005753 for ; Wed, 14 Jan 2004 01:08:06 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id A28948002EF; Wed, 14 Jan 2004 11:08:04 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0E9847Y024120; Wed, 14 Jan 2004 11:08:04 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0E984Mx024116; Wed, 14 Jan 2004 11:08:04 +0200 Date: Wed, 14 Jan 2004 11:08:04 +0200 (EET) From: Ville Nuorvala To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH 2/2] IPv6: strict address checks even on globals in ndisc Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-1422556349-1074070733=:23925" Content-ID: X-archive-position: 2433 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 12471 Lines: 221 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. ---377318441-1422556349-1074070733=:23925 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi Dave, the second part of my patchset contains fixes to the use of addresses in neigbor discovery. RFC 2461 requires that the source address of Neighbor Discovery messages is an address assigned to the sending interface. Duplicate Address Detection should also be interface specific. We don't, for exaple, want a node to DoS itself just because it has two interfaces on the same link and both happen to listen to the same multicast group. If there is a true duplicate on the link, the interface doing DAD will notice it anyway. The attached patch adds a "strict" parameter to ip6_chk_addr() and ip6_get_ifaddr() to allow link-local protocols like ND and DAD to do strict address checks even on addresses with greater scope than link-local. Thanks, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-1422556349-1074070733=:23925 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="ndisc_strict_addr_chk.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="ndisc_strict_addr_chk.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTUxNCAgLT4gMS4xNTE1IA0KIwkg IG5ldC9pcHY2L2FueWNhc3QuYwkxLjkgICAgIC0+IDEuMTAgICANCiMJbmV0 L2lwdjYvaXA2X3R1bm5lbC5jCTEuMTUgICAgLT4gMS4xNiAgIA0KIwkgbmV0 L2lwdjYvZGF0YWdyYW0uYwkxLjEyICAgIC0+IDEuMTMgICANCiMJICAgICBu ZXQvaXB2Ni9pY21wLmMJMS40NSAgICAtPiAxLjQ2ICAgDQojCSAgICAgIG5l dC9pcHY2L3Jhdy5jCTEuNDYgICAgLT4gMS40NyAgIA0KIwkgbmV0L2lwdjYv YWZfaW5ldDYuYwkxLjU4ICAgIC0+IDEuNTkgICANCiMJICAgIG5ldC9pcHY2 L25kaXNjLmMJMS42MCAgICAtPiAxLjYxICAgDQojCSAgICAgbmV0L3NjdHAv aXB2Ni5jCTEuNDkgICAgLT4gMS41MCAgIA0KIwlpbmNsdWRlL25ldC9hZGRy Y29uZi5oCTEuMTEgICAgLT4gMS4xMiAgIA0KIwkgbmV0L2lwdjYvYWRkcmNv bmYuYwkxLjc5ICAgIC0+IDEuODAgICANCiMNCiMgVGhlIGZvbGxvd2luZyBp cyB0aGUgQml0S2VlcGVyIENoYW5nZVNldCBMb2cNCiMgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiMgMDQvMDEvMTMJ dm51b3J2YWxAYW1iZXIuaHV0Lm1lZGlhcG9saS5jb20JMS4xNTE1DQojIERv IHN0cmljdCAoaW50ZXJmYWNlIHNwZWNpZmljKSBhZGRyZXNzIGNoZWNrcyBp biBpcHY2X2Noa19hZGRyKCkgYW5kIGlwdjZfZ2V0X2lmYWRkcigpIHdoZW4N CiMgZG9pbmcgTmVpZ2hib3IgRGlzY292ZXJ5LiBUaGlzIGlzIHJlcXVpcmVk IGJ5IHRoZSBzcGVjaWZpY2F0aW9uIHdoZW4gc2VsZWN0aW5nIGEgc291cmNl DQojIGFkZHJlc3MgZm9yIE5EIG1lc3NhZ2VzLCBhbmQgc2VlbXMgbG9naWNh bCB3aGVuIGRvaW5nIERBRCAoZm9yIGV4YW1wbGUgb24gYSBtdWx0aWhvbWVk IG5vZGUpLg0KIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KIw0KZGlmZiAtTnJ1IGEvaW5jbHVkZS9uZXQvYWRkcmNv bmYuaCBiL2luY2x1ZGUvbmV0L2FkZHJjb25mLmgNCi0tLSBhL2luY2x1ZGUv bmV0L2FkZHJjb25mLmgJVHVlIEphbiAxMyAyMTowMjowOCAyMDA0DQorKysg Yi9pbmNsdWRlL25ldC9hZGRyY29uZi5oCVR1ZSBKYW4gMTMgMjE6MDI6MDgg MjAwNA0KQEAgLTU5LDkgKzU5LDExIEBADQogZXh0ZXJuIGludAkJCWFkZHJj b25mX3NldF9kc3RhZGRyKHZvaWQgKmFyZyk7DQogDQogZXh0ZXJuIGludAkJ CWlwdjZfY2hrX2FkZHIoc3RydWN0IGluNl9hZGRyICphZGRyLA0KLQkJCQkJ ICAgICAgc3RydWN0IG5ldF9kZXZpY2UgKmRldik7DQorCQkJCQkgICAgICBz dHJ1Y3QgbmV0X2RldmljZSAqZGV2LA0KKwkJCQkJICAgICAgaW50IHN0cmlj dCk7DQogZXh0ZXJuIHN0cnVjdCBpbmV0Nl9pZmFkZHIgKglpcHY2X2dldF9p ZmFkZHIoc3RydWN0IGluNl9hZGRyICphZGRyLA0KLQkJCQkJCXN0cnVjdCBu ZXRfZGV2aWNlICpkZXYpOw0KKwkJCQkJCXN0cnVjdCBuZXRfZGV2aWNlICpk ZXYsDQorCQkJCQkJaW50IHN0cmljdCk7DQogZXh0ZXJuIGludAkJCWlwdjZf Z2V0X3NhZGRyKHN0cnVjdCBkc3RfZW50cnkgKmRzdCwgDQogCQkJCQkgICAg ICAgc3RydWN0IGluNl9hZGRyICpkYWRkciwNCiAJCQkJCSAgICAgICBzdHJ1 Y3QgaW42X2FkZHIgKnNhZGRyKTsNCmRpZmYgLU5ydSBhL25ldC9pcHY2L2Fk ZHJjb25mLmMgYi9uZXQvaXB2Ni9hZGRyY29uZi5jDQotLS0gYS9uZXQvaXB2 Ni9hZGRyY29uZi5jCVR1ZSBKYW4gMTMgMjE6MDI6MDggMjAwNA0KKysrIGIv bmV0L2lwdjYvYWRkcmNvbmYuYwlUdWUgSmFuIDEzIDIxOjAyOjA4IDIwMDQN CkBAIC05MDQsNyArOTA0LDcgQEANCiAJcmV0dXJuIGNudDsNCiB9DQogDQot aW50IGlwdjZfY2hrX2FkZHIoc3RydWN0IGluNl9hZGRyICphZGRyLCBzdHJ1 Y3QgbmV0X2RldmljZSAqZGV2KQ0KK2ludCBpcHY2X2Noa19hZGRyKHN0cnVj dCBpbjZfYWRkciAqYWRkciwgc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50 IHN0cmljdCkNCiB7DQogCXN0cnVjdCBpbmV0Nl9pZmFkZHIgKiBpZnA7DQog CXU4IGhhc2ggPSBpcHY2X2FkZHJfaGFzaChhZGRyKTsNCkBAIC05MTQsNyAr OTE0LDcgQEANCiAJCWlmIChpcHY2X2FkZHJfY21wKCZpZnAtPmFkZHIsIGFk ZHIpID09IDAgJiYNCiAJCSAgICAhKGlmcC0+ZmxhZ3MmSUZBX0ZfVEVOVEFU SVZFKSkgew0KIAkJCWlmIChkZXYgPT0gTlVMTCB8fCBpZnAtPmlkZXYtPmRl diA9PSBkZXYgfHwNCi0JCQkgICAgIShpZnAtPnNjb3BlJihJRkFfTElOS3xJ RkFfSE9TVCkpKQ0KKwkJCSAgICAhKGlmcC0+c2NvcGUmKElGQV9MSU5LfElG QV9IT1NUKSB8fCBzdHJpY3QpKQ0KIAkJCQlicmVhazsNCiAJCX0NCiAJfQ0K QEAgLTkzOSw3ICs5MzksNyBAQA0KIAlyZXR1cm4gaWZwICE9IE5VTEw7DQog fQ0KIA0KLXN0cnVjdCBpbmV0Nl9pZmFkZHIgKiBpcHY2X2dldF9pZmFkZHIo c3RydWN0IGluNl9hZGRyICphZGRyLCBzdHJ1Y3QgbmV0X2RldmljZSAqZGV2 KQ0KK3N0cnVjdCBpbmV0Nl9pZmFkZHIgKiBpcHY2X2dldF9pZmFkZHIoc3Ry dWN0IGluNl9hZGRyICphZGRyLCBzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBp bnQgc3RyaWN0KQ0KIHsNCiAJc3RydWN0IGluZXQ2X2lmYWRkciAqIGlmcDsN CiAJdTggaGFzaCA9IGlwdjZfYWRkcl9oYXNoKGFkZHIpOw0KQEAgLTk0OCw3 ICs5NDgsNyBAQA0KIAlmb3IoaWZwID0gaW5ldDZfYWRkcl9sc3RbaGFzaF07 IGlmcDsgaWZwPWlmcC0+bHN0X25leHQpIHsNCiAJCWlmIChpcHY2X2FkZHJf Y21wKCZpZnAtPmFkZHIsIGFkZHIpID09IDApIHsNCiAJCQlpZiAoZGV2ID09 IE5VTEwgfHwgaWZwLT5pZGV2LT5kZXYgPT0gZGV2IHx8DQotCQkJICAgICEo aWZwLT5zY29wZSYoSUZBX0xJTkt8SUZBX0hPU1QpKSkgew0KKwkJCSAgICAh KGlmcC0+c2NvcGUmKElGQV9MSU5LfElGQV9IT1NUKSB8fCBzdHJpY3QpKSB7 DQogCQkJCWluNl9pZmFfaG9sZChpZnApOw0KIAkJCQlicmVhazsNCiAJCQl9 DQpAQCAtMTM4Nyw3ICsxMzg3LDcgQEANCiANCiBvazoNCiANCi0JCWlmcCA9 IGlwdjZfZ2V0X2lmYWRkcigmYWRkciwgZGV2KTsNCisJCWlmcCA9IGlwdjZf Z2V0X2lmYWRkcigmYWRkciwgZGV2LCAxKTsNCiANCiAJCWlmIChpZnAgPT0g TlVMTCAmJiB2YWxpZF9sZnQpIHsNCiAJCQkvKiBEbyBub3QgYWxsb3cgdG8g Y3JlYXRlIHRvbyBtdWNoIG9mIGF1dG9jb25maWd1cmVkDQpAQCAtMjgzMCw3 ICsyODMwLDcgQEANCiAJCQlpZiAoIWlwdjZfYWRkcl9hbnkoJmFkZHIpKQ0K IAkJCQlpcHY2X2Rldl9hY19kZWMoaWZwLT5pZGV2LT5kZXYsICZhZGRyKTsN CiAJCX0NCi0JCWlmICghaXB2Nl9jaGtfYWRkcigmaWZwLT5hZGRyLCBOVUxM KSkNCisJCWlmICghaXB2Nl9jaGtfYWRkcigmaWZwLT5hZGRyLCBpZnAtPmlk ZXYtPmRldiwgMSkpDQogCQkJaXA2X3J0X2FkZHJfZGVsKCZpZnAtPmFkZHIs IGlmcC0+aWRldi0+ZGV2KTsNCiAJCWJyZWFrOw0KIAl9DQpkaWZmIC1OcnUg YS9uZXQvaXB2Ni9hZl9pbmV0Ni5jIGIvbmV0L2lwdjYvYWZfaW5ldDYuYw0K LS0tIGEvbmV0L2lwdjYvYWZfaW5ldDYuYwlUdWUgSmFuIDEzIDIxOjAyOjA4 IDIwMDQNCisrKyBiL25ldC9pcHY2L2FmX2luZXQ2LmMJVHVlIEphbiAxMyAy MTowMjowOCAyMDA0DQpAQCAtMzU1LDcgKzM1NSw3IEBADQogCQkJICovDQog CQkJdjRhZGRyID0gTE9PUEJBQ0s0X0lQVjY7DQogCQkJaWYgKCEoYWRkcl90 eXBlICYgSVBWNl9BRERSX01VTFRJQ0FTVCkpCXsNCi0JCQkJaWYgKCFpcHY2 X2Noa19hZGRyKCZhZGRyLT5zaW42X2FkZHIsIGRldikpIHsNCisJCQkJaWYg KCFpcHY2X2Noa19hZGRyKCZhZGRyLT5zaW42X2FkZHIsIGRldiwgMCkpIHsN CiAJCQkJCWlmIChkZXYpDQogCQkJCQkJZGV2X3B1dChkZXYpOw0KIAkJCQkJ ZXJyID0gLUVBRERSTk9UQVZBSUw7DQpkaWZmIC1OcnUgYS9uZXQvaXB2Ni9h bnljYXN0LmMgYi9uZXQvaXB2Ni9hbnljYXN0LmMNCi0tLSBhL25ldC9pcHY2 L2FueWNhc3QuYwlUdWUgSmFuIDEzIDIxOjAyOjA4IDIwMDQNCisrKyBiL25l dC9pcHY2L2FueWNhc3QuYwlUdWUgSmFuIDEzIDIxOjAyOjA4IDIwMDQNCkBA IC0xMTMsNyArMTEzLDcgQEANCiAJCXJldHVybiAtRVBFUk07DQogCWlmIChp cHY2X2FkZHJfdHlwZShhZGRyKSAmIElQVjZfQUREUl9NVUxUSUNBU1QpDQog CQlyZXR1cm4gLUVJTlZBTDsNCi0JaWYgKGlwdjZfY2hrX2FkZHIoYWRkciwg TlVMTCkpDQorCWlmIChpcHY2X2Noa19hZGRyKGFkZHIsIE5VTEwsIDApKQ0K IAkJcmV0dXJuIC1FSU5WQUw7DQogDQogCXBhYyA9IHNvY2tfa21hbGxvYyhz aywgc2l6ZW9mKHN0cnVjdCBpcHY2X2FjX3NvY2tsaXN0KSwgR0ZQX0tFUk5F TCk7DQpkaWZmIC1OcnUgYS9uZXQvaXB2Ni9kYXRhZ3JhbS5jIGIvbmV0L2lw djYvZGF0YWdyYW0uYw0KLS0tIGEvbmV0L2lwdjYvZGF0YWdyYW0uYwlUdWUg SmFuIDEzIDIxOjAyOjA4IDIwMDQNCisrKyBiL25ldC9pcHY2L2RhdGFncmFt LmMJVHVlIEphbiAxMyAyMTowMjowOCAyMDA0DQpAQCAtMzA3LDcgKzMwNyw3 IEBADQogCQkJCQkJcmV0dXJuIC1FTk9ERVY7DQogCQkJCX0NCiAJCQl9DQot CQkJaWYgKCFpcHY2X2Noa19hZGRyKCZzcmNfaW5mby0+aXBpNl9hZGRyLCBk ZXYpKSB7DQorCQkJaWYgKCFpcHY2X2Noa19hZGRyKCZzcmNfaW5mby0+aXBp Nl9hZGRyLCBkZXYsIDApKSB7DQogCQkJCWlmIChkZXYpDQogCQkJCQlkZXZf cHV0KGRldik7DQogCQkJCWVyciA9IC1FSU5WQUw7DQpkaWZmIC1OcnUgYS9u ZXQvaXB2Ni9pY21wLmMgYi9uZXQvaXB2Ni9pY21wLmMNCi0tLSBhL25ldC9p cHY2L2ljbXAuYwlUdWUgSmFuIDEzIDIxOjAyOjA4IDIwMDQNCisrKyBiL25l dC9pcHY2L2ljbXAuYwlUdWUgSmFuIDEzIDIxOjAyOjA4IDIwMDQNCkBAIC0y OTgsNyArMjk4LDcgQEANCiAJICovDQogCWFkZHJfdHlwZSA9IGlwdjZfYWRk cl90eXBlKCZoZHItPmRhZGRyKTsNCiANCi0JaWYgKGlwdjZfY2hrX2FkZHIo Jmhkci0+ZGFkZHIsIHNrYi0+ZGV2KSkNCisJaWYgKGlwdjZfY2hrX2FkZHIo Jmhkci0+ZGFkZHIsIHNrYi0+ZGV2LCAwKSkNCiAJCXNhZGRyID0gJmhkci0+ ZGFkZHI7DQogDQogCS8qDQpkaWZmIC1OcnUgYS9uZXQvaXB2Ni9pcDZfdHVu bmVsLmMgYi9uZXQvaXB2Ni9pcDZfdHVubmVsLmMNCi0tLSBhL25ldC9pcHY2 L2lwNl90dW5uZWwuYwlUdWUgSmFuIDEzIDIxOjAyOjA4IDIwMDQNCisrKyBi L25ldC9pcHY2L2lwNl90dW5uZWwuYwlUdWUgSmFuIDEzIDIxOjAyOjA4IDIw MDQNCkBAIC03NzcsMTAgKzc3NywxMCBAQA0KIAkJaWYgKHAtPmxpbmspDQog CQkJbGRldiA9IGRldl9nZXRfYnlfaW5kZXgocC0+bGluayk7DQogCQkNCi0J CWlmICgobHR5cGUmSVBWNl9BRERSX1VOSUNBU1QpICYmICFpcHY2X2Noa19h ZGRyKGxhZGRyLCBsZGV2KSkNCisJCWlmIChsdHlwZSZJUFY2X0FERFJfVU5J Q0FTVCAmJiAhaXB2Nl9jaGtfYWRkcihsYWRkciwgbGRldiwgMCkpDQogCQkJ bF9vayA9IDA7DQogCQkNCi0JCWlmICgocnR5cGUmSVBWNl9BRERSX1VOSUNB U1QpICYmIGlwdjZfY2hrX2FkZHIocmFkZHIsIE5VTEwpKQ0KKwkJaWYgKHJ0 eXBlJklQVjZfQUREUl9VTklDQVNUICYmIGlwdjZfY2hrX2FkZHIocmFkZHIs IE5VTEwsIDApKQ0KIAkJCXJfb2sgPSAwOw0KIAkJDQogCQlpZiAobF9vayAm JiByX29rKSB7DQpkaWZmIC1OcnUgYS9uZXQvaXB2Ni9uZGlzYy5jIGIvbmV0 L2lwdjYvbmRpc2MuYw0KLS0tIGEvbmV0L2lwdjYvbmRpc2MuYwlUdWUgSmFu IDEzIDIxOjAyOjA4IDIwMDQNCisrKyBiL25ldC9pcHY2L25kaXNjLmMJVHVl IEphbiAxMyAyMTowMjowOCAyMDA0DQpAQCAtNDM0LDcgKzQzNCw3IEBADQog CWxlbiA9IHNpemVvZihzdHJ1Y3QgaWNtcDZoZHIpICsgc2l6ZW9mKHN0cnVj dCBpbjZfYWRkcik7DQogDQogCS8qIGZvciBhbnljYXN0IG9yIHByb3h5LCBz b2xpY2l0ZWRfYWRkciAhPSBzcmNfYWRkciAqLw0KLQlpZnAgPSBpcHY2X2dl dF9pZmFkZHIoc29saWNpdGVkX2FkZHIsIGRldik7DQorCWlmcCA9IGlwdjZf Z2V0X2lmYWRkcihzb2xpY2l0ZWRfYWRkciwgZGV2LCAxKTsNCiAgCWlmIChp ZnApIHsNCiAJCXNyY19hZGRyID0gc29saWNpdGVkX2FkZHI7DQogCQlpbjZf aWZhX3B1dChpZnApOw0KQEAgLTY4MCw3ICs2ODAsNyBAQA0KIAlzdHJ1Y3Qg aW42X2FkZHIgKnRhcmdldCA9IChzdHJ1Y3QgaW42X2FkZHIgKikmbmVpZ2gt PnByaW1hcnlfa2V5Ow0KIAlpbnQgcHJvYmVzID0gYXRvbWljX3JlYWQoJm5l aWdoLT5wcm9iZXMpOw0KIA0KLQlpZiAoc2tiICYmIGlwdjZfY2hrX2FkZHIo JnNrYi0+bmguaXB2NmgtPnNhZGRyLCBkZXYpKQ0KKwlpZiAoc2tiICYmIGlw djZfY2hrX2FkZHIoJnNrYi0+bmguaXB2NmgtPnNhZGRyLCBkZXYsIDEpKQ0K IAkJc2FkZHIgPSAmc2tiLT5uaC5pcHY2aC0+c2FkZHI7DQogDQogCWlmICgo cHJvYmVzIC09IG5laWdoLT5wYXJtcy0+dWNhc3RfcHJvYmVzKSA8IDApIHsN CkBAIC03NTgsNyArNzU4LDcgQEANCiAJCX0NCiAJfQ0KIA0KLQlpZiAoKGlm cCA9IGlwdjZfZ2V0X2lmYWRkcigmbXNnLT50YXJnZXQsIGRldikpICE9IE5V TEwpIHsNCisJaWYgKChpZnAgPSBpcHY2X2dldF9pZmFkZHIoJm1zZy0+dGFy Z2V0LCBkZXYsIDEpKSAhPSBOVUxMKSB7DQogCQlpZiAoaWZwLT5mbGFncyAm IElGQV9GX1RFTlRBVElWRSkgew0KIAkJCS8qIEFkZHJlc3MgaXMgdGVudGF0 aXZlLiBJZiB0aGUgc291cmNlDQogCQkJICAgaXMgdW5zcGVjaWZpZWQgYWRk cmVzcywgaXQgaXMgc29tZW9uZQ0KQEAgLTk1NSw3ICs5NTUsNyBAQA0KIAkJ CXJldHVybjsNCiAJCX0NCiAJfQ0KLQlpZiAoKGlmcCA9IGlwdjZfZ2V0X2lm YWRkcigmbXNnLT50YXJnZXQsIGRldikpKSB7DQorCWlmICgoaWZwID0gaXB2 Nl9nZXRfaWZhZGRyKCZtc2ctPnRhcmdldCwgZGV2LCAxKSkpIHsNCiAJCWlm IChpZnAtPmZsYWdzICYgSUZBX0ZfVEVOVEFUSVZFKSB7DQogCQkJYWRkcmNv bmZfZGFkX2ZhaWx1cmUoaWZwKTsNCiAJCQlyZXR1cm47DQpkaWZmIC1OcnUg YS9uZXQvaXB2Ni9yYXcuYyBiL25ldC9pcHY2L3Jhdy5jDQotLS0gYS9uZXQv aXB2Ni9yYXcuYwlUdWUgSmFuIDEzIDIxOjAyOjA4IDIwMDQNCisrKyBiL25l dC9pcHY2L3Jhdy5jCVR1ZSBKYW4gMTMgMjE6MDI6MDggMjAwNA0KQEAgLTIy Nyw3ICsyMjcsNyBAQA0KIAkJdjRhZGRyID0gTE9PUEJBQ0s0X0lQVjY7DQog CQlpZiAoIShhZGRyX3R5cGUgJiBJUFY2X0FERFJfTVVMVElDQVNUKSkJew0K IAkJCWVyciA9IC1FQUREUk5PVEFWQUlMOw0KLQkJCWlmICghaXB2Nl9jaGtf YWRkcigmYWRkci0+c2luNl9hZGRyLCBkZXYpKSB7DQorCQkJaWYgKCFpcHY2 X2Noa19hZGRyKCZhZGRyLT5zaW42X2FkZHIsIGRldiwgMCkpIHsNCiAJCQkJ aWYgKGRldikNCiAJCQkJCWRldl9wdXQoZGV2KTsNCiAJCQkJZ290byBvdXQ7 DQpkaWZmIC1OcnUgYS9uZXQvc2N0cC9pcHY2LmMgYi9uZXQvc2N0cC9pcHY2 LmMNCi0tLSBhL25ldC9zY3RwL2lwdjYuYwlUdWUgSmFuIDEzIDIxOjAyOjA4 IDIwMDQNCisrKyBiL25ldC9zY3RwL2lwdjYuYwlUdWUgSmFuIDEzIDIxOjAy OjA4IDIwMDQNCkBAIC01MTAsNyArNTEwLDcgQEANCiAJaWYgKCEodHlwZSAm IElQVjZfQUREUl9VTklDQVNUKSkNCiAJCXJldHVybiAwOw0KIA0KLQlyZXR1 cm4gaXB2Nl9jaGtfYWRkcihpbjYsIE5VTEwpOw0KKwlyZXR1cm4gaXB2Nl9j aGtfYWRkcihpbjYsIE5VTEwsIDApOw0KIH0NCiANCiAvKiBUaGlzIGZ1bmN0 aW9uIGNoZWNrcyBpZiB0aGUgYWRkcmVzcyBpcyBhIHZhbGlkIGFkZHJlc3Mg dG8gYmUgdXNlZCBmb3INCg== ---377318441-1422556349-1074070733=:23925-- From vnuorval@tcs.hut.fi Wed Jan 14 01:10:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 01:10:16 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E99p6H006260 for ; Wed, 14 Jan 2004 01:09:51 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 80FB8800210; Wed, 14 Jan 2004 10:35:12 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0E8ZC7Y024027; Wed, 14 Jan 2004 10:35:12 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0E8ZBNm024023; Wed, 14 Jan 2004 10:35:11 +0200 Date: Wed, 14 Jan 2004 10:35:11 +0200 (EET) From: Ville Nuorvala To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH 1/2] IPv6: stricter checks on link-locals in bind and sendmsg Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-583041426-1074069311=:23925" X-archive-position: 2434 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 11521 Lines: 204 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. ---377318441-583041426-1074069311=:23925 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Dave, I found a couple of suspected bugs related to (source) address handling while rummaging around the code... When binding to a link-local address, inet6_bind() and raw6_bind() only check that an interface is specified and that the address exists, but they don't check if it actually exists on the specified interface. Similarly, in datagram_sent_ctl() we don't check for the possibility of a link-local address when we receive the source address from userspace. The attached patch should fix this behavior. Thanks, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-583041426-1074069311=:23925 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="link_local_bind.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="link_local_bind.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTUxMSAgLT4gMS4xNTEzIA0KIwkg bmV0L2lwdjYvZGF0YWdyYW0uYwkxLjExICAgIC0+IDEuMTIgICANCiMJICAg ICAgbmV0L2lwdjYvcmF3LmMJMS40NSAgICAtPiAxLjQ2ICAgDQojCSBuZXQv aXB2Ni9hZl9pbmV0Ni5jCTEuNTcgICAgLT4gMS41OCAgIA0KIw0KIyBUaGUg Zm9sbG93aW5nIGlzIHRoZSBCaXRLZWVwZXIgQ2hhbmdlU2V0IExvZw0KIyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K IyAwNC8wMS8xMwl2bnVvcnZhbEBjczc4MjI3MDkwLnBwLmh0di5maQkxLjE1 MTINCiMgV2hlbiBiaW5kaW5nIHRvIGEgbGluay1sb2NhbCBhZGRyZXNzLCBj aGVjayB0aGF0IGl0IGFjdHVhbGx5IGV4aXN0cyBvbiB0aGUgc3BlY2lmaWVk IGludGVyZmFjZS4NCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiMgMDQvMDEvMTMJdm51b3J2YWxAYW1iZXIuaHV0 Lm1lZGlhcG9saS5jb20JMS4xNTEzDQojIFdoZW4gc2VuZGluZyBhIGRhdGFn cmFtIHVzaW5nIGEgbGluay1sb2NhbCBzb3VyY2UgYWRkcmVzcywgY2hlY2sg dGhhdCBpdCBhY3R1YWxseSBleGlzdHMgb24gdGhlDQojIHNwZWNpZmllZCBp bnRlcmZhY2UuDQojIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQojDQpkaWZmIC1OcnUgYS9uZXQvaXB2Ni9hZl9pbmV0 Ni5jIGIvbmV0L2lwdjYvYWZfaW5ldDYuYw0KLS0tIGEvbmV0L2lwdjYvYWZf aW5ldDYuYwlXZWQgSmFuIDE0IDAwOjE0OjUxIDIwMDQNCisrKyBiL25ldC9p cHY2L2FmX2luZXQ2LmMJV2VkIEphbiAxNCAwMDoxNDo1MSAyMDA0DQpAQCAt Mjk0LDYgKzI5NCw3IEBADQogCV9fdTMyIHY0YWRkciA9IDA7DQogCXVuc2ln bmVkIHNob3J0IHNudW07DQogCWludCBhZGRyX3R5cGUgPSAwOw0KKwlpbnQg ZXJyID0gMDsNCiANCiAJLyogSWYgdGhlIHNvY2tldCBoYXMgaXRzIG93biBi aW5kIGZ1bmN0aW9uIHRoZW4gdXNlIGl0LiAqLw0KIAlpZiAoc2stPnNrX3By b3QtPmJpbmQpDQpAQCAtMzA1LDI0ICszMDYsNiBAQA0KIAlpZiAoKGFkZHJf dHlwZSAmIElQVjZfQUREUl9NVUxUSUNBU1QpICYmIHNvY2stPnR5cGUgPT0g U09DS19TVFJFQU0pDQogCQlyZXR1cm4gLUVJTlZBTDsNCiANCi0JLyogQ2hl Y2sgaWYgdGhlIGFkZHJlc3MgYmVsb25ncyB0byB0aGUgaG9zdC4gKi8NCi0J aWYgKGFkZHJfdHlwZSA9PSBJUFY2X0FERFJfTUFQUEVEKSB7DQotCQl2NGFk ZHIgPSBhZGRyLT5zaW42X2FkZHIuczZfYWRkcjMyWzNdOw0KLQkJaWYgKGlu ZXRfYWRkcl90eXBlKHY0YWRkcikgIT0gUlROX0xPQ0FMKQ0KLQkJCXJldHVy biAtRUFERFJOT1RBVkFJTDsNCi0JfSBlbHNlIHsNCi0JCWlmIChhZGRyX3R5 cGUgIT0gSVBWNl9BRERSX0FOWSkgew0KLQkJCS8qIGlwdjQgYWRkciBvZiB0 aGUgc29ja2V0IGlzIGludmFsaWQuICBPbmx5IHRoZQ0KLQkJCSAqIHVuc3Bl Y2lmaWVkIGFuZCBtYXBwZWQgYWRkcmVzcyBoYXZlIGEgdjQgZXF1aXZhbGVu dC4NCi0JCQkgKi8NCi0JCQl2NGFkZHIgPSBMT09QQkFDSzRfSVBWNjsNCi0J CQlpZiAoIShhZGRyX3R5cGUgJiBJUFY2X0FERFJfTVVMVElDQVNUKSkJew0K LQkJCQlpZiAoIWlwdjZfY2hrX2FkZHIoJmFkZHItPnNpbjZfYWRkciwgTlVM TCkpDQotCQkJCQlyZXR1cm4gLUVBRERSTk9UQVZBSUw7DQotCQkJfQ0KLQkJ fQ0KLQl9DQotDQogCXNudW0gPSBudG9ocyhhZGRyLT5zaW42X3BvcnQpOw0K IAlpZiAoc251bSAmJiBzbnVtIDwgUFJPVF9TT0NLICYmICFjYXBhYmxlKENB UF9ORVRfQklORF9TRVJWSUNFKSkNCiAJCXJldHVybiAtRUFDQ0VTOw0KQEAg LTMzMSwyMyArMzE0LDU2IEBADQogDQogCS8qIENoZWNrIHRoZXNlIGVycm9y cyAoYWN0aXZlIHNvY2tldCwgZG91YmxlIGJpbmQpLiAqLw0KIAlpZiAoc2st PnNrX3N0YXRlICE9IFRDUF9DTE9TRSB8fCBpbmV0LT5udW0pIHsNCi0JCXJl bGVhc2Vfc29jayhzayk7DQotCQlyZXR1cm4gLUVJTlZBTDsNCisJCWVyciA9 IC1FSU5WQUw7DQorCQlnb3RvIG91dDsNCiAJfQ0KIA0KLQlpZiAoYWRkcl90 eXBlICYgSVBWNl9BRERSX0xJTktMT0NBTCkgew0KLQkJaWYgKGFkZHJfbGVu ID49IHNpemVvZihzdHJ1Y3Qgc29ja2FkZHJfaW42KSAmJg0KLQkJICAgIGFk ZHItPnNpbjZfc2NvcGVfaWQpIHsNCi0JCQkvKiBPdmVycmlkZSBhbnkgZXhp c3RpbmcgYmluZGluZywgaWYgYW5vdGhlciBvbmUNCi0JCQkgKiBpcyBzdXBw bGllZCBieSB1c2VyLg0KLQkJCSAqLw0KLQkJCXNrLT5za19ib3VuZF9kZXZf aWYgPSBhZGRyLT5zaW42X3Njb3BlX2lkOw0KKwkvKiBDaGVjayBpZiB0aGUg YWRkcmVzcyBiZWxvbmdzIHRvIHRoZSBob3N0LiAqLw0KKwlpZiAoYWRkcl90 eXBlID09IElQVjZfQUREUl9NQVBQRUQpIHsNCisJCXY0YWRkciA9IGFkZHIt PnNpbjZfYWRkci5zNl9hZGRyMzJbM107DQorCQlpZiAoaW5ldF9hZGRyX3R5 cGUodjRhZGRyKSAhPSBSVE5fTE9DQUwpIHsNCisJCQllcnIgPSAtRUFERFJO T1RBVkFJTDsNCisJCQlnb3RvIG91dDsNCiAJCX0NCisJfSBlbHNlIHsNCisJ CWlmIChhZGRyX3R5cGUgIT0gSVBWNl9BRERSX0FOWSkgew0KKwkJCXN0cnVj dCBuZXRfZGV2aWNlICpkZXYgPSBOVUxMOw0KKw0KKwkJCWlmIChhZGRyX3R5 cGUgJiBJUFY2X0FERFJfTElOS0xPQ0FMKSB7DQorCQkJCWlmIChhZGRyX2xl biA+PSBzaXplb2Yoc3RydWN0IHNvY2thZGRyX2luNikgJiYNCisJCQkJICAg IGFkZHItPnNpbjZfc2NvcGVfaWQpIHsNCisJCQkJCS8qIE92ZXJyaWRlIGFu eSBleGlzdGluZyBiaW5kaW5nLCBpZiBhbm90aGVyIG9uZQ0KKwkJCQkJICog aXMgc3VwcGxpZWQgYnkgdXNlci4NCisJCQkJCSAqLw0KKwkJCQkJc2stPnNr X2JvdW5kX2Rldl9pZiA9IGFkZHItPnNpbjZfc2NvcGVfaWQ7DQorCQkJCX0N CisJCQkJDQorCQkJCS8qIEJpbmRpbmcgdG8gbGluay1sb2NhbCBhZGRyZXNz IHJlcXVpcmVzIGFuIGludGVyZmFjZSAqLw0KKwkJCQlpZiAoIXNrLT5za19i b3VuZF9kZXZfaWYpIHsNCisJCQkJCWVyciA9IC1FSU5WQUw7DQorCQkJCQln b3RvIG91dDsNCisJCQkJfQ0KKwkJCQlkZXYgPSBkZXZfZ2V0X2J5X2luZGV4 KHNrLT5za19ib3VuZF9kZXZfaWYpOw0KKwkJCQlpZiAoIWRldikgew0KKwkJ CQkJZXJyID0gLUVOT0RFVjsNCisJCQkJCWdvdG8gb3V0Ow0KKwkJCQl9DQor CQkJfQ0KIA0KLQkJLyogQmluZGluZyB0byBsaW5rLWxvY2FsIGFkZHJlc3Mg cmVxdWlyZXMgYW4gaW50ZXJmYWNlICovDQotCQlpZiAoIXNrLT5za19ib3Vu ZF9kZXZfaWYpIHsNCi0JCQlyZWxlYXNlX3NvY2soc2spOw0KLQkJCXJldHVy biAtRUlOVkFMOw0KKwkJCS8qIGlwdjQgYWRkciBvZiB0aGUgc29ja2V0IGlz IGludmFsaWQuICBPbmx5IHRoZQ0KKwkJCSAqIHVuc3BlY2lmaWVkIGFuZCBt YXBwZWQgYWRkcmVzcyBoYXZlIGEgdjQgZXF1aXZhbGVudC4NCisJCQkgKi8N CisJCQl2NGFkZHIgPSBMT09QQkFDSzRfSVBWNjsNCisJCQlpZiAoIShhZGRy X3R5cGUgJiBJUFY2X0FERFJfTVVMVElDQVNUKSkJew0KKwkJCQlpZiAoIWlw djZfY2hrX2FkZHIoJmFkZHItPnNpbjZfYWRkciwgZGV2KSkgew0KKwkJCQkJ aWYgKGRldikNCisJCQkJCQlkZXZfcHV0KGRldik7DQorCQkJCQllcnIgPSAt RUFERFJOT1RBVkFJTDsNCisJCQkJCWdvdG8gb3V0Ow0KKwkJCQl9DQorCQkJ fQ0KKwkJCWlmIChkZXYpDQorCQkJCWRldl9wdXQoZGV2KTsNCiAJCX0NCiAJ fQ0KIA0KQEAgLTM2Miw4ICszNzgsOCBAQA0KIAkvKiBNYWtlIHN1cmUgd2Ug YXJlIGFsbG93ZWQgdG8gYmluZCBoZXJlLiAqLw0KIAlpZiAoc2stPnNrX3By b3QtPmdldF9wb3J0KHNrLCBzbnVtKSkgew0KIAkJaW5ldF9yZXNldF9zYWRk cihzayk7DQotCQlyZWxlYXNlX3NvY2soc2spOw0KLQkJcmV0dXJuIC1FQURE UklOVVNFOw0KKwkJZXJyID0gLUVBRERSSU5VU0U7DQorCQlnb3RvIG91dDsN CiAJfQ0KIA0KIAlpZiAoYWRkcl90eXBlICE9IElQVjZfQUREUl9BTlkpDQpA QCAtMzczLDkgKzM4OSw5IEBADQogCWluZXQtPnNwb3J0ID0gbnRvaHMoaW5l dC0+bnVtKTsNCiAJaW5ldC0+ZHBvcnQgPSAwOw0KIAlpbmV0LT5kYWRkciA9 IDA7DQorb3V0Og0KIAlyZWxlYXNlX3NvY2soc2spOw0KLQ0KLQlyZXR1cm4g MDsNCisJcmV0dXJuIGVycjsNCiB9DQogDQogaW50IGluZXQ2X3JlbGVhc2Uo c3RydWN0IHNvY2tldCAqc29jaykNCmRpZmYgLU5ydSBhL25ldC9pcHY2L2Rh dGFncmFtLmMgYi9uZXQvaXB2Ni9kYXRhZ3JhbS5jDQotLS0gYS9uZXQvaXB2 Ni9kYXRhZ3JhbS5jCVdlZCBKYW4gMTQgMDA6MTQ6NTEgMjAwNA0KKysrIGIv bmV0L2lwdjYvZGF0YWdyYW0uYwlXZWQgSmFuIDE0IDAwOjE0OjUxIDIwMDQN CkBAIC0yNjUsNiArMjY1LDggQEANCiAJaW50IGVyciA9IDA7DQogDQogCWZv ciAoY21zZyA9IENNU0dfRklSU1RIRFIobXNnKTsgY21zZzsgY21zZyA9IENN U0dfTlhUSERSKG1zZywgY21zZykpIHsNCisJCWludCBhZGRyX3R5cGU7DQor CQlzdHJ1Y3QgbmV0X2RldmljZSAqZGV2ID0gTlVMTDsNCiANCiAJCWlmIChj bXNnLT5jbXNnX2xlbiA8IHNpemVvZihzdHJ1Y3QgY21zZ2hkcikgfHwNCiAJ CSAgICAodW5zaWduZWQgbG9uZykoKChjaGFyKiljbXNnIC0gKGNoYXIqKW1z Zy0+bXNnX2NvbnRyb2wpDQpAQCAtMjkxLDE2ICsyOTMsMzAgQEANCiAJCQkJ ZmwtPm9pZiA9IHNyY19pbmZvLT5pcGk2X2lmaW5kZXg7DQogCQkJfQ0KIA0K LQkJCWlmICghaXB2Nl9hZGRyX2FueSgmc3JjX2luZm8tPmlwaTZfYWRkcikp IHsNCi0JCQkJaWYgKCFpcHY2X2Noa19hZGRyKCZzcmNfaW5mby0+aXBpNl9h ZGRyLCBOVUxMKSkgew0KLQkJCQkJZXJyID0gLUVJTlZBTDsNCi0JCQkJCWdv dG8gZXhpdF9mOw0KLQkJCQl9DQorCQkJYWRkcl90eXBlID0gaXB2Nl9hZGRy X3R5cGUoJnNyY19pbmZvLT5pcGk2X2FkZHIpOw0KIA0KLQkJCQlpcHY2X2Fk ZHJfY29weSgmZmwtPmZsNl9zcmMsDQotCQkJCQkgICAgICAgJnNyY19pbmZv LT5pcGk2X2FkZHIpOw0KKwkJCWlmIChpcHY2X2FkZHJfdHlwZSA9PSBJUFY2 X0FERFJfQU5ZKQ0KKwkJCQlicmVhazsNCisJCQkNCisJCQlpZiAoYWRkcl90 eXBlICYgSVBWNl9BRERSX0xJTktMT0NBTCkgew0KKwkJCQlpZiAoIXNyY19p bmZvLT5pcGk2X2lmaW5kZXgpDQorCQkJCQlyZXR1cm4gLUVJTlZBTDsNCisJ CQkJZWxzZSB7DQorCQkJCQlkZXYgPSBkZXZfZ2V0X2J5X2luZGV4KHNyY19p bmZvLT5pcGk2X2lmaW5kZXgpOw0KKwkJCQkJaWYgKCFkZXYpDQorCQkJCQkJ cmV0dXJuIC1FTk9ERVY7DQorCQkJCX0NCisJCQl9DQorCQkJaWYgKCFpcHY2 X2Noa19hZGRyKCZzcmNfaW5mby0+aXBpNl9hZGRyLCBkZXYpKSB7DQorCQkJ CWlmIChkZXYpDQorCQkJCQlkZXZfcHV0KGRldik7DQorCQkJCWVyciA9IC1F SU5WQUw7DQorCQkJCWdvdG8gZXhpdF9mOw0KIAkJCX0NCisJCQlpZiAoZGV2 KQ0KKwkJCQlkZXZfcHV0KGRldik7DQogDQorCQkJaXB2Nl9hZGRyX2NvcHko JmZsLT5mbDZfc3JjLCAmc3JjX2luZm8tPmlwaTZfYWRkcik7DQogCQkJYnJl YWs7DQogDQogCQljYXNlIElQVjZfRkxPV0lORk86DQpkaWZmIC1OcnUgYS9u ZXQvaXB2Ni9yYXcuYyBiL25ldC9pcHY2L3Jhdy5jDQotLS0gYS9uZXQvaXB2 Ni9yYXcuYwlXZWQgSmFuIDE0IDAwOjE0OjUxIDIwMDQNCisrKyBiL25ldC9p cHY2L3Jhdy5jCVdlZCBKYW4gMTQgMDA6MTQ6NTEgMjAwNA0KQEAgLTE5Nywz MSArMTk3LDQ0IEBADQogCWlmIChzay0+c2tfc3RhdGUgIT0gVENQX0NMT1NF KQ0KIAkJZ290byBvdXQ7DQogDQotCWlmIChhZGRyX3R5cGUgJiBJUFY2X0FE RFJfTElOS0xPQ0FMKSB7DQotCQlpZiAoYWRkcl9sZW4gPj0gc2l6ZW9mKHN0 cnVjdCBzb2NrYWRkcl9pbjYpICYmDQotCQkgICAgYWRkci0+c2luNl9zY29w ZV9pZCkgew0KLQkJCS8qIE92ZXJyaWRlIGFueSBleGlzdGluZyBiaW5kaW5n LCBpZiBhbm90aGVyIG9uZQ0KLQkJCSAqIGlzIHN1cHBsaWVkIGJ5IHVzZXIu DQotCQkJICovDQotCQkJc2stPnNrX2JvdW5kX2Rldl9pZiA9IGFkZHItPnNp bjZfc2NvcGVfaWQ7DQotCQl9DQotDQotCQkvKiBCaW5kaW5nIHRvIGxpbmst bG9jYWwgYWRkcmVzcyByZXF1aXJlcyBhbiBpbnRlcmZhY2UgKi8NCi0JCWlm ICghc2stPnNrX2JvdW5kX2Rldl9pZikNCi0JCQlnb3RvIG91dDsNCi0JfQ0K LQ0KIAkvKiBDaGVjayBpZiB0aGUgYWRkcmVzcyBiZWxvbmdzIHRvIHRoZSBo b3N0LiAqLw0KIAlpZiAoYWRkcl90eXBlICE9IElQVjZfQUREUl9BTlkpIHsN CisJCXN0cnVjdCBuZXRfZGV2aWNlICpkZXYgPSBOVUxMOw0KKw0KKwkJaWYg KGFkZHJfdHlwZSAmIElQVjZfQUREUl9MSU5LTE9DQUwpIHsNCisJCQlpZiAo YWRkcl9sZW4gPj0gc2l6ZW9mKHN0cnVjdCBzb2NrYWRkcl9pbjYpICYmDQor CQkJICAgIGFkZHItPnNpbjZfc2NvcGVfaWQpIHsNCisJCQkJLyogT3ZlcnJp ZGUgYW55IGV4aXN0aW5nIGJpbmRpbmcsIGlmIGFub3RoZXINCisJCQkJICog b25lIGlzIHN1cHBsaWVkIGJ5IHVzZXIuDQorCQkJCSAqLw0KKwkJCQlzay0+ c2tfYm91bmRfZGV2X2lmID0gYWRkci0+c2luNl9zY29wZV9pZDsNCisJCQl9 DQorCQkJDQorCQkJLyogQmluZGluZyB0byBsaW5rLWxvY2FsIGFkZHJlc3Mg cmVxdWlyZXMgYW4gaW50ZXJmYWNlICovDQorCQkJaWYgKCFzay0+c2tfYm91 bmRfZGV2X2lmKQ0KKwkJCQlnb3RvIG91dDsNCisNCisJCQlkZXYgPSBkZXZf Z2V0X2J5X2luZGV4KHNrLT5za19ib3VuZF9kZXZfaWYpOw0KKwkJCWlmICgh ZGV2KSB7DQorCQkJCWVyciA9IC1FTk9ERVY7DQorCQkJCWdvdG8gb3V0Ow0K KwkJCX0NCisJCX0NCisJCQ0KIAkJLyogaXB2NCBhZGRyIG9mIHRoZSBzb2Nr ZXQgaXMgaW52YWxpZC4gIE9ubHkgdGhlDQogCQkgKiB1bnBlY2lmaWVkIGFu ZCBtYXBwZWQgYWRkcmVzcyBoYXZlIGEgdjQgZXF1aXZhbGVudC4NCiAJCSAq Lw0KIAkJdjRhZGRyID0gTE9PUEJBQ0s0X0lQVjY7DQogCQlpZiAoIShhZGRy X3R5cGUgJiBJUFY2X0FERFJfTVVMVElDQVNUKSkJew0KIAkJCWVyciA9IC1F QUREUk5PVEFWQUlMOw0KLQkJCWlmICghaXB2Nl9jaGtfYWRkcigmYWRkci0+ c2luNl9hZGRyLCBOVUxMKSkNCisJCQlpZiAoIWlwdjZfY2hrX2FkZHIoJmFk ZHItPnNpbjZfYWRkciwgZGV2KSkgew0KKwkJCQlpZiAoZGV2KQ0KKwkJCQkJ ZGV2X3B1dChkZXYpOw0KIAkJCQlnb3RvIG91dDsNCisJCQl9DQogCQl9DQor CQlpZiAoZGV2KQ0KKwkJCWRldl9wdXQoZGV2KTsNCiAJfQ0KIA0KIAlpbmV0 LT5yY3Zfc2FkZHIgPSBpbmV0LT5zYWRkciA9IHY0YWRkcjsNCg== ---377318441-583041426-1074069311=:23925-- From tsippy.mendelson@intel.com Wed Jan 14 02:38:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 02:38:56 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EAce6H008579 for ; Wed, 14 Jan 2004 02:38:42 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i0EAcYaG019551; Wed, 14 Jan 2004 10:38:34 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i0EAcSCD012797; Wed, 14 Jan 2004 10:38:31 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011412383131246 ; Wed, 14 Jan 2004 12:38:31 +0200 Received: from hasmsx403.ger.corp.intel.com ([143.185.63.109]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 14 Jan 2004 12:38:30 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: del_timer_sync() synchronization rules Date: Wed, 14 Jan 2004 12:38:30 +0200 Message-ID: <2C83850C013A2540861D03054B478C0602012334@hasmsx403.iil.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: del_timer_sync() synchronization rules Thread-Index: AcPajPtbRzUYxo6ZRi2ctZZTwDQbqA== From: "Mendelson, Tsippy" To: Cc: , "iJR ICGJ SW Dev Linux ANS" X-OriginalArrivalTime: 14 Jan 2004 10:38:31.0074 (UTC) FILETIME=[8D7EB820:01C3DA8A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0EAce6H008579 X-archive-position: 2435 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tsippy.mendelson@intel.com Precedence: bulk X-list: netdev Content-Length: 650 Lines: 21 In the header of the del_timer_sync() function in 2.4.x kernels it says: * Caller must disable by some means restarting the timer * for new. In kernel 2.6.1 the header says: * Synchronization rules: callers must prevent restarting of the timer, * otherwise this function is meaningless. Does anyone know what this is about? Does this imply that a timer that restarts itself must use some other means to prevent it from restarting once del_timer_sync was called? (like some kind of terminate flag) If so - isn't this just what dell_timer_sync is supposed to handle properly? If not - then what kind of scenario is this referring to? Tsippy From vnuorval@tcs.hut.fi Wed Jan 14 02:50:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 02:50:50 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EAoa6H010824 for ; Wed, 14 Jan 2004 02:50:37 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id B04CD800307; Wed, 14 Jan 2004 12:50:35 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0EAoZ7Y024425; Wed, 14 Jan 2004 12:50:35 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0EAoYGn024421; Wed, 14 Jan 2004 12:50:35 +0200 Date: Wed, 14 Jan 2004 12:50:34 +0200 (EET) From: Ville Nuorvala To: davem@redhat.com, usagi-core@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: [PATCH|RFC] IPv6: have a proxy discard link-local traffic Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2436 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 1309 Lines: 37 Hi Dave & Co, the patch below causes a router proxying a link-local address to discard traffic sent to it, also sending an ICMPv6 Destination Unreachable, Code 3 message to the source. This behavior is required by the Mobile IPv6 specification (the only user of proxy ND I'm aware of). This seems like reasonable behavior in any case, since the router won't be able to forward the link-local traffic to the proxied node anyway. Thanks, Ville ===== net/ipv6/ip6_output.c 1.48 vs 1.50 ===== --- 1.48/net/ipv6/ip6_output.c Thu Jan 1 22:25:30 2004 +++ 1.50/net/ipv6/ip6_output.c Wed Jan 14 12:08:51 2004 @@ -385,6 +385,15 @@ if (!xfrm6_route_forward(skb)) goto drop; + /* The proxy can't forward traffic sent to a link-local address, + so signal the sender and discard the packet */ + + if (ipv6_addr_type(&hdr->daddr) & IPV6_ADDR_LINKLOCAL && + skb->dev && pneigh_lookup(&nd_tbl, &hdr->daddr, skb->dev, 0)) { + icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_ADDR_UNREACH, + 0, skb->dev); + goto drop; + } /* IPv6 specs say nothing about it, but it is clear that we cannot send redirects to source routed frames. */ -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From pekkas@netcore.fi Wed Jan 14 03:01:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 03:02:13 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EB1s6H011432 for ; Wed, 14 Jan 2004 03:01:55 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0EAxWl30327; Wed, 14 Jan 2004 12:59:32 +0200 Date: Wed, 14 Jan 2004 12:59:32 +0200 (EET) From: Pekka Savola To: Ville Nuorvala cc: davem@redhat.com, , Subject: Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2437 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 1667 Lines: 44 On Wed, 14 Jan 2004, Ville Nuorvala wrote: > the patch below causes a router proxying a link-local address to discard > traffic sent to it, also sending an ICMPv6 Destination Unreachable, Code 3 > message to the source. This behavior is required by the Mobile IPv6 > specification (the only user of proxy ND I'm aware of). > > This seems like reasonable behavior in any case, since the router won't be > able to forward the link-local traffic to the proxied node anyway. Please check out draft-thaler-ipv6-ndproxy-xx.txt -- it used ND proxying (similar to proxy ARP). I fear this change might break that.. > --- 1.48/net/ipv6/ip6_output.c Thu Jan 1 22:25:30 2004 > +++ 1.50/net/ipv6/ip6_output.c Wed Jan 14 12:08:51 2004 > @@ -385,6 +385,15 @@ > if (!xfrm6_route_forward(skb)) > goto drop; > > + /* The proxy can't forward traffic sent to a link-local address, > + so signal the sender and discard the packet */ > + > + if (ipv6_addr_type(&hdr->daddr) & IPV6_ADDR_LINKLOCAL && > + skb->dev && pneigh_lookup(&nd_tbl, &hdr->daddr, skb->dev, 0)) { > + icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_ADDR_UNREACH, > + 0, skb->dev); > + goto drop; > + } > /* IPv6 specs say nothing about it, but it is clear that we cannot > send redirects to source routed frames. > */ > -- > Ville Nuorvala > Research Assistant, Institute of Digital Communications, > Helsinki University of Technology > email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From vnuorval@tcs.hut.fi Wed Jan 14 03:34:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 03:34:32 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EBYI6H012926 for ; Wed, 14 Jan 2004 03:34:18 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 4B12C80030E; Wed, 14 Jan 2004 13:34:17 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0EBYH7Y024562; Wed, 14 Jan 2004 13:34:17 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0EBYGp1024558; Wed, 14 Jan 2004 13:34:17 +0200 Date: Wed, 14 Jan 2004 13:34:16 +0200 (EET) From: Ville Nuorvala To: netfilter-devel@lists.netfilter.org, davem@redhat.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-531813261-1074080056=:24125" X-archive-position: 2438 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 9622 Lines: 182 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. ---377318441-531813261-1074080056=:24125 Content-Type: TEXT/PLAIN; charset=US-ASCII Sorry about that, here's the patch. Shouldn't try to do too many things at once... Regards, Ville On Wed, 14 Jan 2004, Ville Nuorvala wrote: > Hello all, > > a proxy needs to capture and process Neighbor Solicitations on behalf of > the proxied node. Normal multicast NS messages are already handled by the > existing neigbor discovery code, but unicast NS messages used for Neighbor > Unreachability Detection will only be handled by the proxy if it captures > the packets for local processing. I think the cleanest solution for this > is a netfilter module (which I have incidentally written already :) > > The attached patch contains the afore mentioned module. > > Any comments are welcome! > > Thanks, > Ville > -- > Ville Nuorvala > Research Assistant, Institute of Digital Communications, > Helsinki University of Technology > email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 > -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-531813261-1074080056=:24125 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="nf_proxy_nd.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="nf_proxy_nd.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTUxNSAgLT4gMS4xNTE2IA0KIwlu ZXQvaXB2Ni9uZXRmaWx0ZXIvTWFrZWZpbGUJMS4xMiAgICAtPiAxLjEzICAg DQojCW5ldC9pcHY2L2lwdjZfc3ltcy5jCTEuMTggICAgLT4gMS4xOSAgIA0K IwluZXQvaXB2Ni9uZXRmaWx0ZXIvS2NvbmZpZwkxLjQgICAgIC0+IDEuNSAg ICANCiMJICAgICAgICAgICAgICAgKG5ldykJICAgICAgICAtPiAxLjEgICAg IG5ldC9pcHY2L25ldGZpbHRlci9pcDZfcHJveHlfbmQuYw0KIw0KIyBUaGUg Zm9sbG93aW5nIGlzIHRoZSBCaXRLZWVwZXIgQ2hhbmdlU2V0IExvZw0KIyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K IyAwNC8wMS8xMwl2bnVvcnZhbEBhbWJlci5odXQubWVkaWFwb2xpLmNvbQkx LjE1MTYNCiMgQSBwcm94eSBuZWVkcyB0byBjYXB0dXJlIGFuZCBwcm9jZXNz IE5laWdoYm9yIFNvbGljaXRhdGlvbnMgb24gYmVoYWxmIG9mIHRoZSBwcm94 aWVkIG5vZGUuDQojIE5vcm1hbCBtdWx0aWNhc3QgTlMgbWVzc2FnZXMgYXJl IGFscmVhZHkgaGFuZGxlZCBieSB0aGUgZXhpc3RpbmcgbmVpZ2JvciBkaXNj b3ZlcnkgY29kZSwNCiMgYnV0IHVuaWNhc3QgTlMgbWVzc2FnZXMgdXNlZCBm b3IgTmVpZ2hib3IgVW5yZWFjaGFiaWxpdHkgRGV0ZWN0aW9uIHdpbGwgb25s eSBiZSBoYW5kbGVkIGJ5DQojIHRoZSBwcm94eSBpZiBpdCBjYXB0dXJlcyB0 aGUgcGFja2V0cyBmb3IgbG9jYWwgcHJvY2Vzc2luZyB1c2luZyBuZXRmaWx0 ZXIuDQojIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQojDQpkaWZmIC1OcnUgYS9uZXQvaXB2Ni9pcHY2X3N5bXMuYyBi L25ldC9pcHY2L2lwdjZfc3ltcy5jDQotLS0gYS9uZXQvaXB2Ni9pcHY2X3N5 bXMuYwlUdWUgSmFuIDEzIDIxOjAyOjE4IDIwMDQNCisrKyBiL25ldC9pcHY2 L2lwdjZfc3ltcy5jCVR1ZSBKYW4gMTMgMjE6MDI6MTggMjAwNA0KQEAgLTE3 LDYgKzE3LDkgQEANCiBFWFBPUlRfU1lNQk9MKGlwNl9yb3V0ZV9vdXRwdXQp Ow0KICNpZmRlZiBDT05GSUdfTkVURklMVEVSDQogRVhQT1JUX1NZTUJPTChp cDZfcm91dGVfbWVfaGFyZGVyKTsNCitFWFBPUlRfU1lNQk9MKGlwdjZfc2tp cF9leHRoZHIpOw0KK0VYUE9SVF9TWU1CT0woaXA2X2lucHV0KTsNCitFWFBP UlRfU1lNQk9MKG5kX3RibCk7DQogI2VuZGlmDQogRVhQT1JUX1NZTUJPTChh ZGRyY29uZl9sb2NrKTsNCiBFWFBPUlRfU1lNQk9MKGlwdjZfc2V0c29ja29w dCk7DQpkaWZmIC1OcnUgYS9uZXQvaXB2Ni9uZXRmaWx0ZXIvS2NvbmZpZyBi L25ldC9pcHY2L25ldGZpbHRlci9LY29uZmlnDQotLS0gYS9uZXQvaXB2Ni9u ZXRmaWx0ZXIvS2NvbmZpZwlUdWUgSmFuIDEzIDIxOjAyOjE4IDIwMDQNCisr KyBiL25ldC9pcHY2L25ldGZpbHRlci9LY29uZmlnCVR1ZSBKYW4gMTMgMjE6 MDI6MTggMjAwNA0KQEAgLTIxOCw1ICsyMTgsMTQgQEANCiAJICBUbyBjb21w aWxlIGl0IGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlLiAgSWYgdW5zdXJl LCBzYXkgTi4NCiANCiAjZGVwX3RyaXN0YXRlICcgIExPRyB0YXJnZXQgc3Vw cG9ydCcgQ09ORklHX0lQNl9ORl9UQVJHRVRfTE9HICRDT05GSUdfSVA2X05G X0lQVEFCTEVTDQorDQorY29uZmlnIElQNl9ORl9QUk9YWV9ORA0KKwl0cmlz dGF0ZSAiQ29tcGxldGUgcHJveHkgTmVpZ2JvciBEaXNjb3Zlcnkgc3VwcG9y dCINCisJaGVscA0KKwkgIFRoaXMgZmlsdGVyIGFsbG93cyB0aGUgcHJveHkg dG8gcHJvY2VzcyB1bmljYXN0IE5laWdoYm9yDQorCSAgVW5yZWFjaGFiaWxp dHkgUHJvYmVzIGFzIHdlbGwgYXMgbm9ybWFsIG11bHRpY2FzdA0KKwkgIE5l aWdoYm9yIFNvbGljaXRhdGlvbnMgc2VudCB0byB0aGUgcHJveGllZCBub2Rl Lg0KKw0KKwkgIFRvIGNvbXBpbGUgaXQgYXMgYSBtb2R1bGUsIGNob29zZSBN IGhlcmUuICBJZiB1bnN1cmUsIHNheSBOLg0KIGVuZG1lbnUNCiANCmRpZmYg LU5ydSBhL25ldC9pcHY2L25ldGZpbHRlci9NYWtlZmlsZSBiL25ldC9pcHY2 L25ldGZpbHRlci9NYWtlZmlsZQ0KLS0tIGEvbmV0L2lwdjYvbmV0ZmlsdGVy L01ha2VmaWxlCVR1ZSBKYW4gMTMgMjE6MDI6MTggMjAwNA0KKysrIGIvbmV0 L2lwdjYvbmV0ZmlsdGVyL01ha2VmaWxlCVR1ZSBKYW4gMTMgMjE6MDI6MTgg MjAwNA0KQEAgLTIyLDMgKzIyLDQgQEANCiBvYmotJChDT05GSUdfSVA2X05G X1FVRVVFKSArPSBpcDZfcXVldWUubw0KIG9iai0kKENPTkZJR19JUDZfTkZf VEFSR0VUX0xPRykgKz0gaXA2dF9MT0cubw0KIG9iai0kKENPTkZJR19JUDZf TkZfTUFUQ0hfSEwpICs9IGlwNnRfaGwubw0KK29iai0kKENPTkZJR19JUDZf TkZfUFJPWFlfTkQpICs9IGlwNl9wcm94eV9uZC5vDQpkaWZmIC1OcnUgYS9u ZXQvaXB2Ni9uZXRmaWx0ZXIvaXA2X3Byb3h5X25kLmMgYi9uZXQvaXB2Ni9u ZXRmaWx0ZXIvaXA2X3Byb3h5X25kLmMNCi0tLSAvZGV2L251bGwJV2VkIERl YyAzMSAxNjowMDowMCAxOTY5DQorKysgYi9uZXQvaXB2Ni9uZXRmaWx0ZXIv aXA2X3Byb3h5X25kLmMJVHVlIEphbiAxMyAyMTowMjoxOCAyMDA0DQpAQCAt MCwwICsxLDEwMCBAQA0KKy8qDQorICogQ29weXJpZ2h0IChDKTIwMDMgSGVs c2lua2kgVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5DQorICogDQorICogVGhp cyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmli dXRlIGl0IGFuZC9vciBtb2RpZnkNCisgKiBpdCB1bmRlciB0aGUgdGVybXMg b2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hl ZCBieQ0KKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhl ciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yDQorICogKGF0IHlvdXIg b3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4NCisgKiANCisgKiBUaGlzIHBy b2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxs IGJlIHVzZWZ1bCwNCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdp dGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZg0KKyAqIE1FUkNI QU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9T RS4gIFNlZSB0aGUNCisgKiBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBm b3IgbW9yZSBkZXRhaWxzLg0KKyAqIA0KKyAqIFlvdSBzaG91bGQgaGF2ZSBy ZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNl bnNlDQorICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3Jp dGUgdG8gdGhlIEZyZWUgU29mdHdhcmUNCisgKiBGb3VuZGF0aW9uLCBJbmMu LCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIx MTEtMTMwNyAgVVNBDQorICoNCisgKiBMaW51eCBJTkVUNiBpbXBsZW1lbnRh dGlvbiANCisgKg0KKyAqIG5mIGhvb2sgZm9yIGNhcHR1cmluZyB1bmljYXN0 IG5laWdoYm9yIGRpc2NvdmVyeSBtZXNzYWdlcyBzbyBhIHByb3h5DQorICog Y2FuIHBhcnRpY2lwYXRlIGluIE5laWdoYm9yIFVucmVhY2hhYmlsaXR5IERl dGVjdGlvbiBvbiBiZWhhbGYgb2YgaXRzDQorICogY2xpZW50DQorICoNCisg KiBBdXRob3JzDQorICoJVmlsbGUgTnVvcnZhbGEJCTx2bnVvcnZhbEB0Y3Mu aHV0LmZpPgkNCisgKi8NCisNCisjaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+ DQorI2luY2x1ZGUgPGxpbnV4L25ldGZpbHRlcl9pcHY2Lmg+DQorI2luY2x1 ZGUgPG5ldC9pcHY2Lmg+DQorI2luY2x1ZGUgPG5ldC9uZGlzYy5oPg0KKw0K K01PRFVMRV9MSUNFTlNFKCJHUEwiKTsNCitNT0RVTEVfQVVUSE9SKCJWaWxs ZSBOdW9ydmFsYSA8dm51b3J2YWxAdGNzLmh1dC5maT4iKTsNCitNT0RVTEVf REVTQ1JJUFRJT04oIklQdjYgUHJveHkgTkQgZmlsdGVyIik7DQorDQorDQor c3RhdGljIHVuc2lnbmVkIGludCBpcDZfcHJveHlfbmRfaG9vayh1bnNpZ25l ZCBpbnQgaG9va251bSwNCisJCQkJICAgICAgc3RydWN0IHNrX2J1ZmYgKipw c2tiLA0KKwkJCQkgICAgICBjb25zdCBzdHJ1Y3QgbmV0X2RldmljZSAqaW4s DQorCQkJCSAgICAgIGNvbnN0IHN0cnVjdCBuZXRfZGV2aWNlICpvdXQsDQor CQkJCSAgICAgIGludCAoKm9rZm4pKHN0cnVjdCBza19idWZmICopKQ0KK3sN CisJc3RydWN0IHNrX2J1ZmYgKnNrYiA9ICpwc2tiOw0KKwlzdHJ1Y3QgaXB2 NmhkciAqaXB2NmggPSBza2ItPm5oLmlwdjZoOw0KKwl1OCBuZXh0aGRyID0g aXB2NmgtPm5leHRoZHI7DQorCWludCBvZmZzZXQ7DQorCXN0cnVjdCBpbjZf YWRkciAqZGFkZHIgPSAmc2tiLT5uaC5pcHY2aC0+ZGFkZHI7DQorCXN0cnVj dCBpY21wNmhkciBtc2c7DQorDQorCWlmIChpcHY2X2V4dF9oZHIobmV4dGhk cikpIHsNCisJCW9mZnNldCA9IGlwdjZfc2tpcF9leHRoZHIoc2tiLCBzaXpl b2Yoc3RydWN0IGlwdjZoZHIpLCANCisJCQkJCSAgJm5leHRoZHIsIA0KKwkJ CQkJICBza2ItPmxlbiAtIHNpemVvZihzdHJ1Y3QgaXB2NmhkcikpOw0KKwkJ aWYgKG9mZnNldCA8IDApDQorCQkJcmV0dXJuIE5GX0FDQ0VQVDsNCisJfSBl bHNlDQorCQlvZmZzZXQgPSBzaXplb2Yoc3RydWN0IGlwdjZoZHIpOw0KKw0K KwkvKiBjYXB0dXJlIHVuaWNhc3QgTlVEIHByb2JlcyBvbiBiZWhhbGYgb2Yg dGhlIHByb3hpZWQgbm9kZSAqLw0KKwlpZiAobmV4dGhkciA9PSBJUFBST1RP X0lDTVBWNiAmJiANCisJICAgIGlwdjZfYWRkcl90eXBlKGRhZGRyKSAmIElQ VjZfQUREUl9VTklDQVNUICYmIA0KKwkgICAgIXNrYl9jb3B5X2JpdHMoc2ti LCBvZmZzZXQsICZtc2csIHNpemVvZihtc2cpKSkgew0KKwkJaW50IGlpZjsg DQorCQlzdHJ1Y3QgbmV0X2RldmljZSAqZGV2Ow0KKwkJc3dpdGNoIChtc2cu aWNtcDZfdHlwZSkgew0KKwkJY2FzZSBORElTQ19ORUlHSEJPVVJfU09MSUNJ VEFUSU9OOg0KKwkJCWlpZiA9ICgoc3RydWN0IGluZXQ2X3NrYl9wYXJtICop c2tiLT5jYiktPmlpZjsNCisJCQlkZXYgPSBfX2Rldl9nZXRfYnlfaW5kZXgo aWlmKTsNCisJCQlpZiAoZGV2ICYmIHBuZWlnaF9sb29rdXAoJm5kX3RibCwg ZGFkZHIsIGRldiwgMCkpIHsNCisJCQkJaXA2X2lucHV0KHNrYik7DQorCQkJ CXJldHVybiBORl9TVE9MRU47DQorCQkJfQ0KKwkJfQ0KKwl9DQorCXJldHVy biBORl9BQ0NFUFQ7DQorfQ0KKw0KK3N0YXRpYyBzdHJ1Y3QgbmZfaG9va19v cHMgaXA2X3Byb3h5X25kX29wcyA9IHsNCisJLmhvb2sgPSBpcDZfcHJveHlf bmRfaG9vaywNCisJLm93bmVyID0gVEhJU19NT0RVTEUsDQorCS5wZiA9IFBG X0lORVQ2LA0KKwkuaG9va251bSA9IE5GX0lQNl9QUkVfUk9VVElORywNCisJ LnByaW9yaXR5ID0gTkZfSVA2X1BSSV9MQVNULA0KK307DQorDQorDQorc3Rh dGljIGludCBfX2luaXQgaXA2X3Byb3h5X25kX2luaXQodm9pZCkNCit7DQor CXJldHVybiBuZl9yZWdpc3Rlcl9ob29rKCZpcDZfcHJveHlfbmRfb3BzKTsN Cit9DQorDQorc3RhdGljIHZvaWQgX19leGl0IGlwNl9wcm94eV9uZF9leGl0 KHZvaWQpDQorew0KKwluZl91bnJlZ2lzdGVyX2hvb2soJmlwNl9wcm94eV9u ZF9vcHMpOw0KK30NCisNCittb2R1bGVfaW5pdChpcDZfcHJveHlfbmRfaW5p dCk7DQorbW9kdWxlX2V4aXQoaXA2X3Byb3h5X25kX2V4aXQpOw0KKw0K ---377318441-531813261-1074080056=:24125-- From vnuorval@tcs.hut.fi Wed Jan 14 03:56:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 03:56:57 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EBuV6H013574 for ; Wed, 14 Jan 2004 03:56:34 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 29B3780030A; Wed, 14 Jan 2004 13:25:43 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0EBPg7Y024533; Wed, 14 Jan 2004 13:25:42 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0EBPg8f024529; Wed, 14 Jan 2004 13:25:42 +0200 Date: Wed, 14 Jan 2004 13:25:42 +0200 (EET) From: Ville Nuorvala To: netfilter-devel@lists.netfilter.org, davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2439 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 711 Lines: 20 Hello all, a proxy needs to capture and process Neighbor Solicitations on behalf of the proxied node. Normal multicast NS messages are already handled by the existing neigbor discovery code, but unicast NS messages used for Neighbor Unreachability Detection will only be handled by the proxy if it captures the packets for local processing. I think the cleanest solution for this is a netfilter module (which I have incidentally written already :) The attached patch contains the afore mentioned module. Any comments are welcome! Thanks, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From yoshfuji@linux-ipv6.org Wed Jan 14 04:04:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 04:04:18 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EC446H014415 for ; Wed, 14 Jan 2004 04:04:04 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id C870233CA5; Wed, 14 Jan 2004 21:04:27 +0900 (JST) Date: Wed, 14 Jan 2004 21:04:27 +0900 (JST) Message-Id: <20040114.210427.104284595.yoshfuji@linux-ipv6.org> To: vnuorval@tcs.hut.fi Cc: netfilter-devel@lists.netfilter.org, davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA 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: 2440 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 Content-Length: 365 Lines: 8 In article (at Wed, 14 Jan 2004 13:25:42 +0200 (EET)), Ville Nuorvala says: > the packets for local processing. I think the cleanest solution for this > is a netfilter module (which I have incidentally written already :) I don't think so. Proxy should not depend on netfilter. --yoshfuji From amir.noam@intel.com Wed Jan 14 07:01:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 07:01:44 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EF1Q6H026196 for ; Wed, 14 Jan 2004 07:01:28 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i0EF13aG015482; Wed, 14 Jan 2004 15:01:03 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i0EF0QCJ003868; Wed, 14 Jan 2004 15:00:53 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011417005206506 ; Wed, 14 Jan 2004 17:00:52 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i0EF0ohb004225; Wed, 14 Jan 2004 17:00:51 +0200 (IST) From: Amir Noam To: "Jeff Garzik" Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces Date: Wed, 14 Jan 2004 17:00:50 +0200 User-Agent: KMail/1.5.3 Cc: , References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401141700.50119.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2441 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 878 Lines: 23 On Sunday 11 January 2004 11:59 pm, Jeff Garzik wrote: > ioctls are a pain for 32/64-bit emulation layers too. It seems > much easier to define a netlink protocol family of some sort and > communicate that way. It seems that a lot of different suggestions were made so far about the best way to pass messages unrelated to a specific interface to the kernel (char device, netlink, sysfs), all with their own advantages and disadvantages. Until the preferred method is decided on for 2.6, is there a real objection to using a generic socket ioctl for bonding in the *2.4* kernel? (again, given that several other modules already use such a scheme, and won't change that behavior in 2.4) It would be nice to have the support for dynamically adding/removing bonding interfaces in 2.4, and 2.4.25 is about to be the last 2.4 kernel that accepts new features. -- Amir From vnuorval@tcs.hut.fi Wed Jan 14 07:22:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 07:22:44 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EFMU6H027036 for ; Wed, 14 Jan 2004 07:22:31 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id CD333800311; Wed, 14 Jan 2004 17:22:29 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0EFMT7Y025561; Wed, 14 Jan 2004 17:22:29 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0EFMT5q025557; Wed, 14 Jan 2004 17:22:29 +0200 Date: Wed, 14 Jan 2004 17:22:28 +0200 (EET) From: Ville Nuorvala To: Pekka Savola , yoshfuji@linux-ipv6.org Cc: davem@redhat.com, usagi-core@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2442 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 2724 Lines: 69 On Wed, 14 Jan 2004, Pekka Savola wrote: > Please check out draft-thaler-ipv6-ndproxy-xx.txt -- it used ND > proxying (similar to proxy ARP). Oh yes, true. I actually checked out the draft some months ago... (And just re-read it :) > I fear this change might break that.. I don't think it does. Here's why: The current proxy ND implementation in the kernel only captures multicast NS messages. A unicast NS (i.e. a NUD probe) won't be captured by the proxy, in stead it tries to _route_ it to the proxied node. No matter what scope the proxied address is, this is incorrect behavior since: 1) the packet will probably be routed back to the original link, unless the proxy has a more specific route to the proxied node 2) traffic to a link-local address can't be routed to another link 3) an attempt to route a packet back to the original link would just cause the proxy to send another NS for the address it is already proxying, eventually resulting in a ICMPv6 Destination Unreachable, Code 3 message after the NS has timed out. 4) the unicast ND messages are forwarded to at most one other interface, not all of them 5) multicast (ND) messages aren't forwarded at all because of 2 and since multicast routing isn't implemented yet AFAIK :( 6) the proxying router decreases the hop count of the packet, thus breaking the ND protocols (and other link-local protocols that rely on the hop count to remain unchanged. The traditional proxy described in RFC 2461 is a router, what Thaler describes is closer to a bridge. The protocol described in Thaler's draft can't rely on routing for what it is doing, in stead it must AFAICS bypass the routing altogether, either inside the kernel, or by pushing the traffic through user space. These are the real problems you have to address if you want to implement Thaler's draft on Linux. In contrast, since 2 always applies (i.e. you can't route link-locals) this patch only removes the unnecessary steps described in 3 before the error message is sent. This shouldn't break anything wrt to draft-thaler-ipv6-ndproxy-01.txt (as explained), and is a requirement in the MIPv6 specifiaction (as previously mentioned :) My other patch with the netfilter module captures the NUD probes once it proxies an addresses, but the intermediate node faces all the listed problems before it can even start acting as a proxy for it. Similarly, issues 1, 2, 5 and 6 will also cause problems for other protocols than just ND, assuming you don't want all traffic to bypass routing. Regards, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From shemminger@osdl.org Wed Jan 14 11:37:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 11:38:01 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EJbl6H004565 for ; Wed, 14 Jan 2004 11:37:47 -0800 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 i0EJbYo04751; Wed, 14 Jan 2004 11:37:34 -0800 Date: Wed, 14 Jan 2004 11:37:34 -0800 From: Stephen Hemminger To: Matt Mackall Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-Id: <20040114113734.4e9a0865.shemminger@osdl.org> In-Reply-To: <20040114071303.GG28521@waste.org> References: <20040113154610.38f5934c.shemminger@osdl.org> <20040113155921.342db463.davem@redhat.com> <20040113161303.20f1159d.shemminger@osdl.org> <20040114071303.GG28521@waste.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (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: 2443 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 Content-Length: 419 Lines: 10 > Unfortunately sscanf("eth0-not-allocated", "eth%d", &i) fools it. > Which may or may not be worth worrying about. Hmmm, the old code would have assigned "eth0" in that case, new code would assign "eth1". Other difference is in the case of whitespace. scanf("white space0", "white space%d", &i) because any whitespace matches multiple whitespace characters. Is it worth making a separate explicit match routine? From oxymoron@waste.org Wed Jan 14 11:52:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 11:52:26 -0800 (PST) Received: from waste.org (waste.org [209.173.204.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EJq56H005862 for ; Wed, 14 Jan 2004 11:52:06 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0EJpwhm023038; Wed, 14 Jan 2004 13:51:58 -0600 Received: (from oxymoron@localhost) by waste.org (8.12.3/8.12.3/Debian-6.6) id i0EJpwJN023032; Wed, 14 Jan 2004 13:51:58 -0600 Date: Wed, 14 Jan 2004 13:51:57 -0600 From: Matt Mackall To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-ID: <20040114195157.GJ28521@waste.org> References: <20040113154610.38f5934c.shemminger@osdl.org> <20040113155921.342db463.davem@redhat.com> <20040113161303.20f1159d.shemminger@osdl.org> <20040114071303.GG28521@waste.org> <20040114113734.4e9a0865.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040114113734.4e9a0865.shemminger@osdl.org> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new X-archive-position: 2444 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 Content-Length: 879 Lines: 20 On Wed, Jan 14, 2004 at 11:37:34AM -0800, Stephen Hemminger wrote: > > > Unfortunately sscanf("eth0-not-allocated", "eth%d", &i) fools it. > > Which may or may not be worth worrying about. > > Hmmm, the old code would have assigned "eth0" in that case, new code > would assign "eth1". Other difference is in the case of whitespace. > scanf("white space0", "white space%d", &i) > because any whitespace matches multiple whitespace characters. > > Is it worth making a separate explicit match routine? I think it's probably easier to just add O(1) lookup and then do explicit lookups on eth0..ethx. As Dave's pointed out, fast lookups are wanted elsewhere. I made a quick hack to make the sscanf trick work (try scanning for "eth%d%c" and insisting that %c not get parsed) but it was not pretty. -- Matt Mackall : http://www.selenic.com : Linux development and consulting From davem@pizda.ninka.net Wed Jan 14 12:19:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 12:19:14 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EKJ06H006894 for ; Wed, 14 Jan 2004 12:19:00 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA25193; Wed, 14 Jan 2004 12:11:55 -0800 Date: Wed, 14 Jan 2004 12:11:55 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: mpm@selenic.com, netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-Id: <20040114121155.7dabd70e.davem@redhat.com> In-Reply-To: <20040114113734.4e9a0865.shemminger@osdl.org> References: <20040113154610.38f5934c.shemminger@osdl.org> <20040113155921.342db463.davem@redhat.com> <20040113161303.20f1159d.shemminger@osdl.org> <20040114071303.GG28521@waste.org> <20040114113734.4e9a0865.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2445 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: 882 Lines: 20 On Wed, 14 Jan 2004 11:37:34 -0800 Stephen Hemminger wrote: > > Unfortunately sscanf("eth0-not-allocated", "eth%d", &i) fools it. > > Which may or may not be worth worrying about. > > Hmmm, the old code would have assigned "eth0" in that case, new code > would assign "eth1". Other difference is in the case of whitespace. > scanf("white space0", "white space%d", &i) > because any whitespace matches multiple whitespace characters. > > Is it worth making a separate explicit match routine? My only concern right now is that, since we're in the middle of 2.6.x, we not break semantics of such a core routine like this one. Although I'm willing to accept that certain cases are just rediculious and not worth worrying about, just try your best to create a version of the patch that matches current behavior as best as possible and we'll work from that. From jt@bougret.hpl.hp.com Wed Jan 14 13:39:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 13:39:29 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0ELdB6H012274 for ; Wed, 14 Jan 2004 13:39:16 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id D87BC1C028BB; Wed, 14 Jan 2004 13:39:08 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id NAA29577; Wed, 14 Jan 2004 13:39:08 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1AgsjE-0005vD-00; Wed, 14 Jan 2004 13:39:08 -0800 Date: Wed, 14 Jan 2004 13:39:08 -0800 To: Stephen Hemminger , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-ID: <20040114213908.GA22653@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: 2446 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 Content-Length: 1075 Lines: 24 Stephen Hemminger wrote : > > When using pseudo network devices, and really big machines; there is > sometimes a need to have a lot of network devices. This replaces the > existing 2.6.1 limit of 100 entries an was O(n^2) > with a algorithm that will handle up to 32768 entries with O(n) behaviour. You may want to be careful about buffer overflow in dev->name. The old code did not check for it, because it was replacing '%d' with a most 2 char ('0' to '99'). The new code may create overflow for device names such as : 'reallylongname%d' And you don't seem the catch that (unless I overlooked something). The problem is more messy that it looks like, because there is no sane way to handle overflow. You can return an error to the driver, and the driver may bail out properly (or crash), but the end user has no way to overcome the issue and get its card loaded (short of editing the driver and recompiling the kernel). So, there is a bit of auding to do first. I know for example the HostAP create such long names. But that's only my humble opinion ;-) Jean From romieu@fr.zoreil.com Wed Jan 14 14:36:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 14:36:55 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EMaZ6H014246 for ; Wed, 14 Jan 2004 14:36:36 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0EMXpsW007116; Wed, 14 Jan 2004 23:33:51 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0EMXpbF007115; Wed, 14 Jan 2004 23:33:51 +0100 Date: Wed, 14 Jan 2004 23:33:50 +0100 From: Francois Romieu To: netdev@oss.sgi.com Cc: jgarzik@pobox.com Subject: [patch] 2.6.1-bk1-netdev4 - latent bug Message-ID: <20040114233350.A4646@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 2447 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 2001 Lines: 62 Hi, (disclaimer: I have not been especially brilliant these last days, so handle with care) the following patch against -netdev4 should fix an error which appears in every r8169 driver (-vanilla, -mm, -netdev, -my). The patch will not apply against plain 2.6.x due to endianness conflict. I will regenerate a serie for 2.6.1-bk1 in a few minutes. It has not been tested so far but it could be a decent candidate for lock-up under stress. Please review rtl8169_tx_interrupt/rtl8169_start_xmit and/or test if you can. - possible tx descriptor index overflow (assume tp->dirty_tx = NUM_TX_DESC/2, tp->cur_tx = NUM_TX_DESC - 1 for example); - the status of an inadequate descriptor is checked. When tx_dirty == 1, one should not necessarily notice a difference. drivers/net/r8169.c | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) diff -puN drivers/net/r8169.c~r8169-tx-index-overflow drivers/net/r8169.c --- linux-2.6.1-bk1-netdev4/drivers/net/r8169.c~r8169-tx-index-overflow 2004-01-14 23:16:58.000000000 +0100 +++ linux-2.6.1-bk1-netdev4-fr/drivers/net/r8169.c 2004-01-14 23:16:58.000000000 +0100 @@ -1341,8 +1341,7 @@ static void rtl8169_tx_interrupt(struct net_device *dev, struct rtl8169_private *tp, void *ioaddr) { - unsigned long dirty_tx, tx_left = 0; - int entry = tp->cur_tx % NUM_TX_DESC; + unsigned long dirty_tx, tx_left; assert(dev != NULL); assert(tp != NULL); @@ -1352,8 +1351,9 @@ rtl8169_tx_interrupt(struct net_device * tx_left = tp->cur_tx - dirty_tx; while (tx_left > 0) { - if (!(le32_to_cpu(tp->TxDescArray[entry].status) & OWNbit)) { - int cur = dirty_tx % NUM_TX_DESC; + int cur = dirty_tx % NUM_TX_DESC; + + if (!(le32_to_cpu(tp->TxDescArray[cur].status) & OWNbit)) { struct sk_buff *skb = tp->Tx_skbuff[cur]; /* FIXME: is it really accurate for TxErr ? */ @@ -1365,7 +1365,6 @@ rtl8169_tx_interrupt(struct net_device * dev_kfree_skb_irq(skb); dirty_tx++; tx_left--; - entry++; } } _ From mashirle@us.ibm.com Wed Jan 14 14:50:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 14:50:48 -0800 (PST) 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.9) with SMTP id i0EMoH6H014961 for ; Wed, 14 Jan 2004 14:50:25 -0800 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 i0F077bO012470; Wed, 14 Jan 2004 16:07:09 -0800 From: Shirley Ma Organization: IBM Linux To: "David S. Miller" Subject: Re: [PATCH] New Patch Implementation for IPv6 MIB:ipv6InterfaceTable Date: Wed, 14 Jan 2004 14:48:55 -0800 User-Agent: KMail/1.4.3 Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com References: <200310141032.23998.mashirle@us.ibm.com> <200310201600.10016.mashirle@us.ibm.com> <20031020210433.27e25240.davem@redhat.com> In-Reply-To: <20031020210433.27e25240.davem@redhat.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_JP4IC6JIGMLAEM9J54WO" Message-Id: <200401141448.55531.mashirle@us.ibm.com> X-archive-position: 2448 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: 12356 Lines: 364 --------------Boundary-00=_JP4IC6JIGMLAEM9J54WO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > It looks fine but I cannot merge it at this time. Linus wants > only critical bug fixes for nowin 2.6.x > > Maybe in 2.6.1, 2.6.2 or later we can merge this in. This patch is against 2.6.1 kernel. Thanks Shirley Ma IBM Linux Technology Center --------------Boundary-00=_JP4IC6JIGMLAEM9J54WO Content-Type: text/x-diff; charset="iso-8859-1"; name="linux-2.6.1-ipv6mib1.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux-2.6.1-ipv6mib1.patch" diff -urN linux-2.6.1/include/linux/rtnetlink.h linux-2.6.1-ipv6mib1/include/linux/rtnetlink.h --- linux-2.6.1/include/linux/rtnetlink.h 2004-01-08 22:59:55.000000000 -0800 +++ linux-2.6.1-ipv6mib1/include/linux/rtnetlink.h 2004-01-12 13:40:09.000000000 -0800 @@ -558,9 +558,18 @@ IFLA_INET6_CONF, /* sysctl parameters */ IFLA_INET6_STATS, /* statistics */ IFLA_INET6_MCAST, /* MC things. What of them? */ + IFLA_INET6_CACHEINFO, /* time values and max reasm size */ }; -#define IFLA_INET6_MAX IFLA_INET6_MCAST +struct ifla_cacheinfo +{ + __u32 max_reasm_len; + __u32 tstamp; /* ipv6InterfaceTable updated timestamp */ + __u32 reachable_time; + __u32 retrans_time; +}; + +#define IFLA_INET6_MAX IFLA_INET6_CACHEINFO /***************************************************************** * Traffic control messages. @@ -611,6 +620,7 @@ #define RTMGRP_IPV6_IFADDR 0x100 #define RTMGRP_IPV6_MROUTE 0x200 #define RTMGRP_IPV6_ROUTE 0x400 +#define RTMGRP_IPV6_IFINFO 0x800 #define RTMGRP_DECnet_IFADDR 0x1000 #define RTMGRP_DECnet_ROUTE 0x4000 diff -urN linux-2.6.1/include/net/if_inet6.h linux-2.6.1-ipv6mib1/include/net/if_inet6.h --- linux-2.6.1/include/net/if_inet6.h 2004-01-08 23:00:04.000000000 -0800 +++ linux-2.6.1-ipv6mib1/include/net/if_inet6.h 2004-01-12 13:40:09.000000000 -0800 @@ -183,6 +183,7 @@ struct inet6_dev *next; struct ipv6_devconf cnf; struct ipv6_devstat stats; + unsigned long tstamp; /* ipv6InterfaceTable update timestamp */ }; extern struct ipv6_devconf ipv6_devconf; diff -urN linux-2.6.1/include/net/ndisc.h linux-2.6.1-ipv6mib1/include/net/ndisc.h --- linux-2.6.1/include/net/ndisc.h 2004-01-08 22:59:55.000000000 -0800 +++ linux-2.6.1-ipv6mib1/include/net/ndisc.h 2004-01-12 13:40:09.000000000 -0800 @@ -98,6 +98,17 @@ extern void igmp6_cleanup(void); +#ifdef CONFIG_SYSCTL +extern int ndisc_ifinfo_sysctl_change(ctl_table *ctl, + int write, + struct file * filp, + void __user *buffer, + size_t *lenp); +#endif + +extern void inet6_ifinfo_notify(int event, + struct inet6_dev *idev); + static inline struct neighbour * ndisc_get_neigh(struct net_device *dev, struct in6_addr *addr) { diff -urN linux-2.6.1/include/net/neighbour.h linux-2.6.1-ipv6mib1/include/net/neighbour.h --- linux-2.6.1/include/net/neighbour.h 2004-01-08 23:00:04.000000000 -0800 +++ linux-2.6.1-ipv6mib1/include/net/neighbour.h 2004-01-12 13:40:09.000000000 -0800 @@ -47,6 +47,9 @@ #include #include +#ifdef CONFIG_SYSCTL +#include +#endif #define NUD_IN_TIMER (NUD_INCOMPLETE|NUD_DELAY|NUD_PROBE) #define NUD_VALID (NUD_PERMANENT|NUD_NOARP|NUD_REACHABLE|NUD_PROBE|NUD_STALE|NUD_DELAY) @@ -206,8 +209,11 @@ extern int neigh_delete(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg); extern void neigh_app_ns(struct neighbour *n); -extern int neigh_sysctl_register(struct net_device *dev, struct neigh_parms *p, - int p_id, int pdev_id, char *p_name); +extern int neigh_sysctl_register(struct net_device *dev, + struct neigh_parms *p, + int p_id, int pdev_id, + char *p_name, + proc_handler *proc_handler); extern void neigh_sysctl_unregister(struct neigh_parms *p); /* diff -urN linux-2.6.1/net/core/neighbour.c linux-2.6.1-ipv6mib1/net/core/neighbour.c --- linux-2.6.1/net/core/neighbour.c 2004-01-08 22:59:06.000000000 -0800 +++ linux-2.6.1-ipv6mib1/net/core/neighbour.c 2004-01-12 13:40:09.000000000 -0800 @@ -1629,7 +1629,8 @@ }; int neigh_sysctl_register(struct net_device *dev, struct neigh_parms *p, - int p_id, int pdev_id, char *p_name) + int p_id, int pdev_id, char *p_name, + proc_handler *handler) { struct neigh_sysctl_table *t = kmalloc(sizeof(*t), GFP_KERNEL); const char *dev_name_source = NULL; @@ -1643,6 +1644,10 @@ t->neigh_vars[1].data = &p->ucast_probes; t->neigh_vars[2].data = &p->app_probes; t->neigh_vars[3].data = &p->retrans_time; + if (handler) { + t->neigh_vars[3].proc_handler = handler; + t->neigh_vars[3].extra1 = dev; + } t->neigh_vars[4].data = &p->base_reachable_time; t->neigh_vars[5].data = &p->delay_probe_time; t->neigh_vars[6].data = &p->gc_staletime; diff -urN linux-2.6.1/net/ipv4/arp.c linux-2.6.1-ipv6mib1/net/ipv4/arp.c --- linux-2.6.1/net/ipv4/arp.c 2004-01-08 22:59:56.000000000 -0800 +++ linux-2.6.1-ipv6mib1/net/ipv4/arp.c 2004-01-12 13:40:09.000000000 -0800 @@ -1122,7 +1122,7 @@ arp_proc_init(); #ifdef CONFIG_SYSCTL neigh_sysctl_register(NULL, &arp_tbl.parms, NET_IPV4, - NET_IPV4_NEIGH, "ipv4"); + NET_IPV4_NEIGH, "ipv4", NULL); #endif register_netdevice_notifier(&arp_netdev_notifier); } diff -urN linux-2.6.1/net/ipv4/devinet.c linux-2.6.1-ipv6mib1/net/ipv4/devinet.c --- linux-2.6.1/net/ipv4/devinet.c 2004-01-08 22:59:19.000000000 -0800 +++ linux-2.6.1-ipv6mib1/net/ipv4/devinet.c 2004-01-12 13:40:09.000000000 -0800 @@ -155,7 +155,7 @@ dev_hold(dev); #ifdef CONFIG_SYSCTL neigh_sysctl_register(dev, in_dev->arp_parms, NET_IPV4, - NET_IPV4_NEIGH, "ipv4"); + NET_IPV4_NEIGH, "ipv4", NULL); #endif write_lock_bh(&inetdev_lock); dev->ip_ptr = in_dev; @@ -910,7 +910,7 @@ devinet_sysctl_unregister(&in_dev->cnf); neigh_sysctl_unregister(in_dev->arp_parms); neigh_sysctl_register(dev, in_dev->arp_parms, NET_IPV4, - NET_IPV4_NEIGH, "ipv4"); + NET_IPV4_NEIGH, "ipv4", NULL); devinet_sysctl_register(in_dev, &in_dev->cnf); #endif break; diff -urN linux-2.6.1/net/ipv6/addrconf.c linux-2.6.1-ipv6mib1/net/ipv6/addrconf.c --- linux-2.6.1/net/ipv6/addrconf.c 2004-01-08 23:00:03.000000000 -0800 +++ linux-2.6.1-ipv6mib1/net/ipv6/addrconf.c 2004-01-14 14:22:59.000000000 -0800 @@ -373,9 +373,10 @@ write_unlock_bh(&addrconf_lock); ipv6_mc_init_dev(ndev); - + ndev->tstamp = jiffies; #ifdef CONFIG_SYSCTL - neigh_sysctl_register(dev, ndev->nd_parms, NET_IPV6, NET_IPV6_NEIGH, "ipv6"); + neigh_sysctl_register(dev, ndev->nd_parms, NET_IPV6, + NET_IPV6_NEIGH, "ipv6", &ndisc_ifinfo_sysctl_change); addrconf_sysctl_register(ndev, &ndev->cnf); #endif } @@ -1890,6 +1891,8 @@ rt6_mtu_change(dev, dev->mtu); idev->cnf.mtu6 = dev->mtu; } + idev->tstamp = jiffies; + inet6_ifinfo_notify(RTM_NEWLINK, idev); /* If the changed mtu during down is lower than IPV6_MIN_MTU stop IPv6 on this interface. */ @@ -1921,7 +1924,7 @@ if (idev) { addrconf_sysctl_unregister(&idev->cnf); neigh_sysctl_unregister(idev->nd_parms); - neigh_sysctl_register(dev, idev->nd_parms, NET_IPV6, NET_IPV6_NEIGH, "ipv6"); + neigh_sysctl_register(dev, idev->nd_parms, NET_IPV6, NET_IPV6_NEIGH, "ipv6", &ndisc_ifinfo_sysctl_change); addrconf_sysctl_register(idev, &idev->cnf); } #endif @@ -2023,6 +2026,10 @@ else ipv6_mc_down(idev); + /* Step 5: netlink notification of this interface */ + idev->tstamp = jiffies; + inet6_ifinfo_notify(RTM_NEWLINK, idev); + /* Shot the device (if unregistered) */ if (how == 1) { @@ -2724,17 +2731,19 @@ #endif } -static int inet6_fill_ifinfo(struct sk_buff *skb, struct net_device *dev, - struct inet6_dev *idev, - int type, u32 pid, u32 seq) +static int inet6_fill_ifinfo(struct sk_buff *skb, struct inet6_dev *idev, + u32 pid, u32 seq, int event) { + struct net_device *dev = idev->dev; __s32 *array = NULL; struct ifinfomsg *r; struct nlmsghdr *nlh; unsigned char *b = skb->tail; struct rtattr *subattr; + __u32 mtu = dev->mtu; + struct ifla_cacheinfo ci; - nlh = NLMSG_PUT(skb, pid, seq, type, sizeof(*r)); + nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*r)); if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; r = NLMSG_DATA(nlh); r->ifi_family = AF_INET6; @@ -2749,6 +2758,13 @@ RTA_PUT(skb, IFLA_IFNAME, strlen(dev->name)+1, dev->name); + if (dev->addr_len) + RTA_PUT(skb, IFLA_ADDRESS, dev->addr_len, dev->dev_addr); + + RTA_PUT(skb, IFLA_MTU, sizeof(mtu), &mtu); + if (dev->ifindex != dev->iflink) + RTA_PUT(skb, IFLA_LINK, sizeof(int), &dev->iflink); + subattr = (struct rtattr*)skb->tail; RTA_PUT(skb, IFLA_PROTINFO, 0, NULL); @@ -2756,6 +2772,14 @@ /* return the device flags */ RTA_PUT(skb, IFLA_INET6_FLAGS, sizeof(__u32), &idev->if_flags); + /* return interface cacheinfo */ + ci.max_reasm_len = IPV6_MAXPLEN; + ci.tstamp = (__u32)(TIME_DELTA(idev->tstamp, INITIAL_JIFFIES) / HZ * 100 + + TIME_DELTA(idev->tstamp, INITIAL_JIFFIES) % HZ * 100 / HZ); + ci.reachable_time = idev->nd_parms->reachable_time; + ci.retrans_time = idev->nd_parms->retrans_time; + RTA_PUT(skb, IFLA_INET6_CACHEINFO, sizeof(ci), &ci); + /* return the device sysctl params */ if ((array = kmalloc(DEVCONF_MAX * sizeof(*array), GFP_ATOMIC)) == NULL) goto rtattr_failure; @@ -2790,8 +2814,8 @@ continue; if ((idev = in6_dev_get(dev)) == NULL) continue; - err = inet6_fill_ifinfo(skb, dev, idev, RTM_NEWLINK, - NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq); + err = inet6_fill_ifinfo(skb, idev, NETLINK_CB(cb->skb).pid, + cb->nlh->nlmsg_seq, RTM_NEWLINK); in6_dev_put(idev); if (err <= 0) break; @@ -2802,6 +2826,26 @@ return skb->len; } +void inet6_ifinfo_notify(int event, struct inet6_dev *idev) +{ + struct sk_buff *skb; + /* 128 bytes ?? */ + int size = NLMSG_SPACE(sizeof(struct ifinfomsg)+128); + + skb = alloc_skb(size, GFP_ATOMIC); + if (!skb) { + netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFINFO, ENOBUFS); + return; + } + if (inet6_fill_ifinfo(skb, idev, 0, 0, event) < 0) { + kfree_skb(skb); + netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFINFO, EINVAL); + return; + } + NETLINK_CB(skb).dst_groups = RTMGRP_IPV6_IFINFO; + netlink_broadcast(rtnl, skb, 0, RTMGRP_IPV6_IFINFO, GFP_ATOMIC); +} + static struct rtnetlink_link inet6_rtnetlink_table[RTM_MAX - RTM_BASE + 1] = { [RTM_GETLINK - RTM_BASE] = { .dumpit = inet6_dump_ifinfo, }, [RTM_NEWADDR - RTM_BASE] = { .doit = inet6_rtm_newaddr, }, diff -urN linux-2.6.1/net/ipv6/ndisc.c linux-2.6.1-ipv6mib1/net/ipv6/ndisc.c --- linux-2.6.1/net/ipv6/ndisc.c 2004-01-08 22:59:44.000000000 -0800 +++ linux-2.6.1-ipv6mib1/net/ipv6/ndisc.c 2004-01-12 16:18:02.000000000 -0800 @@ -1115,6 +1115,8 @@ if (rtime < HZ/10) rtime = HZ/10; in6_dev->nd_parms->retrans_time = rtime; + in6_dev->tstamp = jiffies; + inet6_ifinfo_notify(RTM_NEWLINK, in6_dev); } rtime = ntohl(ra_msg->reachable_time); @@ -1128,6 +1130,8 @@ in6_dev->nd_parms->base_reachable_time = rtime; in6_dev->nd_parms->gc_staletime = 3 * rtime; in6_dev->nd_parms->reachable_time = neigh_rand_reach_time(rtime); + in6_dev->tstamp = jiffies; + inet6_ifinfo_notify(RTM_NEWLINK, in6_dev); } } } @@ -1492,6 +1496,21 @@ .notifier_call = ndisc_netdev_event, }; +#ifdef CONFIG_SYSCTL +int ndisc_ifinfo_sysctl_change(struct ctl_table *ctl, int write, struct file * filp, void __user *buffer, size_t *lenp) +{ + struct net_device *dev = ctl->extra1; + struct inet6_dev *idev; + + if (write && dev && (idev = in6_dev_get(dev)) != NULL) { + idev->tstamp = jiffies; + inet6_ifinfo_notify(RTM_NEWLINK, idev); + in6_dev_put(idev); + } + return proc_dointvec(ctl, write, filp, buffer, lenp); +} +#endif + int __init ndisc_init(struct net_proto_family *ops) { struct ipv6_pinfo *np; @@ -1522,7 +1541,8 @@ neigh_table_init(&nd_tbl); #ifdef CONFIG_SYSCTL - neigh_sysctl_register(NULL, &nd_tbl.parms, NET_IPV6, NET_IPV6_NEIGH, "ipv6"); + neigh_sysctl_register(NULL, &nd_tbl.parms, NET_IPV6, NET_IPV6_NEIGH, + "ipv6", &ndisc_ifinfo_sysctl_change); #endif register_netdevice_notifier(&ndisc_netdev_notifier); --------------Boundary-00=_JP4IC6JIGMLAEM9J54WO-- From mashirle@us.ibm.com Wed Jan 14 14:53:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 14:53:29 -0800 (PST) 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.9) with SMTP id i0EMrC6H015315 for ; Wed, 14 Jan 2004 14:53:12 -0800 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 i0F0B0bO012477; Wed, 14 Jan 2004 16:11:01 -0800 From: Shirley Ma Organization: IBM Linux To: "David S. Miller" Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c Date: Wed, 14 Jan 2004 14:52:51 -0800 User-Agent: KMail/1.4.3 Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, xma@us.ibm.com References: <200312021240.PAA01536@yakov.inr.ac.ru> <200312051214.48076.mashirle@us.ibm.com> <20031205123133.3743fe39.davem@redhat.com> In-Reply-To: <20031205123133.3743fe39.davem@redhat.com> MIME-Version: 1.0 Message-Id: <200401141450.43806.mashirle@us.ibm.com> Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_3W4IHK7H5IB4D0GPKYUU" X-archive-position: 2449 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: 21170 Lines: 727 --------------Boundary-00=_3W4IHK7H5IB4D0GPKYUU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > "sizeof(unsigned long)" evaluates to 8 on 64-bit systems, > yet you assume it always evaluated to 4 as on 32-bit systems. > > Maybe it would be wiser to explicitly use 'u32' and 'u64' for > the types of the snmp counters? > > This has always been a sore area. This is the new patch against 2.6.1 kernel. Thanks Shirley Ma IBM Linux Technology Center --------------Boundary-00=_3W4IHK7H5IB4D0GPKYUU Content-Type: text/x-diff; charset="iso-8859-1"; name="linux-2.6.1-ipv6mib2-64.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux-2.6.1-ipv6mib2-64.patch" diff -urN linux-2.6.1/include/net/snmp.h linux-2.6.1-ipv6mib2-64/include/net/snmp.h --- linux-2.6.1/include/net/snmp.h 2004-01-08 22:59:26.000000000 -0800 +++ linux-2.6.1-ipv6mib2-64/include/net/snmp.h 2004-01-13 13:45:23.000000000 -0800 @@ -49,24 +49,24 @@ */ struct ip_mib { - unsigned long IpInReceives; - unsigned long IpInHdrErrors; - unsigned long IpInAddrErrors; - unsigned long IpForwDatagrams; - unsigned long IpInUnknownProtos; - unsigned long IpInDiscards; - unsigned long IpInDelivers; - unsigned long IpOutRequests; - unsigned long IpOutDiscards; - unsigned long IpOutNoRoutes; - unsigned long IpReasmTimeout; - unsigned long IpReasmReqds; - unsigned long IpReasmOKs; - unsigned long IpReasmFails; - unsigned long IpFragOKs; - unsigned long IpFragFails; - unsigned long IpFragCreates; - unsigned long __pad[0]; + __u64 IpInReceives; + __u64 IpInHdrErrors; + __u64 IpInAddrErrors; + __u64 IpForwDatagrams; + __u64 IpInUnknownProtos; + __u64 IpInDiscards; + __u64 IpInDelivers; + __u64 IpOutRequests; + __u64 IpOutDiscards; + __u64 IpOutNoRoutes; + __u64 IpReasmTimeout; + __u64 IpReasmReqds; + __u64 IpReasmOKs; + __u64 IpReasmFails; + __u64 IpFragOKs; + __u64 IpFragFails; + __u64 IpFragCreates; + __u64 __pad[0]; }; /* @@ -74,29 +74,29 @@ */ struct ipv6_mib { - unsigned long Ip6InReceives; - unsigned long Ip6InHdrErrors; - unsigned long Ip6InTooBigErrors; - unsigned long Ip6InNoRoutes; - unsigned long Ip6InAddrErrors; - unsigned long Ip6InUnknownProtos; - unsigned long Ip6InTruncatedPkts; - unsigned long Ip6InDiscards; - unsigned long Ip6InDelivers; - unsigned long Ip6OutForwDatagrams; - unsigned long Ip6OutRequests; - unsigned long Ip6OutDiscards; - unsigned long Ip6OutNoRoutes; - unsigned long Ip6ReasmTimeout; - unsigned long Ip6ReasmReqds; - unsigned long Ip6ReasmOKs; - unsigned long Ip6ReasmFails; - unsigned long Ip6FragOKs; - unsigned long Ip6FragFails; - unsigned long Ip6FragCreates; - unsigned long Ip6InMcastPkts; - unsigned long Ip6OutMcastPkts; - unsigned long __pad[0]; + __u64 Ip6InReceives; + __u64 Ip6InHdrErrors; + __u64 Ip6InTooBigErrors; + __u64 Ip6InNoRoutes; + __u64 Ip6InAddrErrors; + __u64 Ip6InUnknownProtos; + __u64 Ip6InTruncatedPkts; + __u64 Ip6InDiscards; + __u64 Ip6InDelivers; + __u64 Ip6OutForwDatagrams; + __u64 Ip6OutRequests; + __u64 Ip6OutDiscards; + __u64 Ip6OutNoRoutes; + __u64 Ip6ReasmTimeout; + __u64 Ip6ReasmReqds; + __u64 Ip6ReasmOKs; + __u64 Ip6ReasmFails; + __u64 Ip6FragOKs; + __u64 Ip6FragFails; + __u64 Ip6FragCreates; + __u64 Ip6InMcastPkts; + __u64 Ip6OutMcastPkts; + __u64 __pad[0]; }; /* @@ -105,34 +105,34 @@ */ struct icmp_mib { - unsigned long IcmpInMsgs; - unsigned long IcmpInErrors; - unsigned long IcmpInDestUnreachs; - unsigned long IcmpInTimeExcds; - unsigned long IcmpInParmProbs; - unsigned long IcmpInSrcQuenchs; - unsigned long IcmpInRedirects; - unsigned long IcmpInEchos; - unsigned long IcmpInEchoReps; - unsigned long IcmpInTimestamps; - unsigned long IcmpInTimestampReps; - unsigned long IcmpInAddrMasks; - unsigned long IcmpInAddrMaskReps; - unsigned long IcmpOutMsgs; - unsigned long IcmpOutErrors; - unsigned long IcmpOutDestUnreachs; - unsigned long IcmpOutTimeExcds; - unsigned long IcmpOutParmProbs; - unsigned long IcmpOutSrcQuenchs; - unsigned long IcmpOutRedirects; - unsigned long IcmpOutEchos; - unsigned long IcmpOutEchoReps; - unsigned long IcmpOutTimestamps; - unsigned long IcmpOutTimestampReps; - unsigned long IcmpOutAddrMasks; - unsigned long IcmpOutAddrMaskReps; - unsigned long dummy; - unsigned long __pad[0]; + __u64 IcmpInMsgs; + __u64 IcmpInErrors; + __u64 IcmpInDestUnreachs; + __u64 IcmpInTimeExcds; + __u64 IcmpInParmProbs; + __u64 IcmpInSrcQuenchs; + __u64 IcmpInRedirects; + __u64 IcmpInEchos; + __u64 IcmpInEchoReps; + __u64 IcmpInTimestamps; + __u64 IcmpInTimestampReps; + __u64 IcmpInAddrMasks; + __u64 IcmpInAddrMaskReps; + __u64 IcmpOutMsgs; + __u64 IcmpOutErrors; + __u64 IcmpOutDestUnreachs; + __u64 IcmpOutTimeExcds; + __u64 IcmpOutParmProbs; + __u64 IcmpOutSrcQuenchs; + __u64 IcmpOutRedirects; + __u64 IcmpOutEchos; + __u64 IcmpOutEchoReps; + __u64 IcmpOutTimestamps; + __u64 IcmpOutTimestampReps; + __u64 IcmpOutAddrMasks; + __u64 IcmpOutAddrMaskReps; + __u64 dummy; + __u64 __pad[0]; }; /* @@ -140,40 +140,35 @@ */ struct icmpv6_mib { - unsigned long Icmp6InMsgs; - unsigned long Icmp6InErrors; - - unsigned long Icmp6InDestUnreachs; - unsigned long Icmp6InPktTooBigs; - unsigned long Icmp6InTimeExcds; - unsigned long Icmp6InParmProblems; - - unsigned long Icmp6InEchos; - unsigned long Icmp6InEchoReplies; - unsigned long Icmp6InGroupMembQueries; - unsigned long Icmp6InGroupMembResponses; - unsigned long Icmp6InGroupMembReductions; - unsigned long Icmp6InRouterSolicits; - unsigned long Icmp6InRouterAdvertisements; - unsigned long Icmp6InNeighborSolicits; - unsigned long Icmp6InNeighborAdvertisements; - unsigned long Icmp6InRedirects; - - unsigned long Icmp6OutMsgs; - - unsigned long Icmp6OutDestUnreachs; - unsigned long Icmp6OutPktTooBigs; - unsigned long Icmp6OutTimeExcds; - unsigned long Icmp6OutParmProblems; - - unsigned long Icmp6OutEchoReplies; - unsigned long Icmp6OutRouterSolicits; - unsigned long Icmp6OutNeighborSolicits; - unsigned long Icmp6OutNeighborAdvertisements; - unsigned long Icmp6OutRedirects; - unsigned long Icmp6OutGroupMembResponses; - unsigned long Icmp6OutGroupMembReductions; - unsigned long __pad[0]; + __u64 Icmp6InMsgs; + __u64 Icmp6InErrors; + __u64 Icmp6InDestUnreachs; + __u64 Icmp6InPktTooBigs; + __u64 Icmp6InTimeExcds; + __u64 Icmp6InParmProblems; + __u64 Icmp6InEchos; + __u64 Icmp6InEchoReplies; + __u64 Icmp6InGroupMembQueries; + __u64 Icmp6InGroupMembResponses; + __u64 Icmp6InGroupMembReductions; + __u64 Icmp6InRouterSolicits; + __u64 Icmp6InRouterAdvertisements; + __u64 Icmp6InNeighborSolicits; + __u64 Icmp6InNeighborAdvertisements; + __u64 Icmp6InRedirects; + __u64 Icmp6OutMsgs; + __u64 Icmp6OutDestUnreachs; + __u64 Icmp6OutPktTooBigs; + __u64 Icmp6OutTimeExcds; + __u64 Icmp6OutParmProblems; + __u64 Icmp6OutEchoReplies; + __u64 Icmp6OutRouterSolicits; + __u64 Icmp6OutNeighborSolicits; + __u64 Icmp6OutNeighborAdvertisements; + __u64 Icmp6OutRedirects; + __u64 Icmp6OutGroupMembResponses; + __u64 Icmp6OutGroupMembReductions; + __u64 __pad[0]; }; /* @@ -182,21 +177,21 @@ */ struct tcp_mib { - unsigned long TcpRtoAlgorithm; - unsigned long TcpRtoMin; - unsigned long TcpRtoMax; - unsigned long TcpMaxConn; - unsigned long TcpActiveOpens; - unsigned long TcpPassiveOpens; - unsigned long TcpAttemptFails; - unsigned long TcpEstabResets; - unsigned long TcpCurrEstab; - unsigned long TcpInSegs; - unsigned long TcpOutSegs; - unsigned long TcpRetransSegs; - unsigned long TcpInErrs; - unsigned long TcpOutRsts; - unsigned long __pad[0]; + __u64 TcpRtoAlgorithm; + __u64 TcpRtoMin; + __u64 TcpRtoMax; + __u64 TcpMaxConn; + __u64 TcpActiveOpens; + __u64 TcpPassiveOpens; + __u64 TcpAttemptFails; + __u64 TcpEstabResets; + __u64 TcpCurrEstab; + __u64 TcpInSegs; + __u64 TcpOutSegs; + __u64 TcpRetransSegs; + __u64 TcpInErrs; + __u64 TcpOutRsts; + __u64 __pad[0]; }; /* @@ -205,110 +200,110 @@ */ struct udp_mib { - unsigned long UdpInDatagrams; - unsigned long UdpNoPorts; - unsigned long UdpInErrors; - unsigned long UdpOutDatagrams; - unsigned long __pad[0]; + __u64 UdpInDatagrams; + __u64 UdpNoPorts; + __u64 UdpInErrors; + __u64 UdpOutDatagrams; + __u64 __pad[0]; }; /* draft-ietf-sigtran-sctp-mib-07.txt */ struct sctp_mib { - unsigned long SctpCurrEstab; - unsigned long SctpActiveEstabs; - unsigned long SctpPassiveEstabs; - unsigned long SctpAborteds; - unsigned long SctpShutdowns; - unsigned long SctpOutOfBlues; - unsigned long SctpChecksumErrors; - unsigned long SctpOutCtrlChunks; - unsigned long SctpOutOrderChunks; - unsigned long SctpOutUnorderChunks; - unsigned long SctpInCtrlChunks; - unsigned long SctpInOrderChunks; - unsigned long SctpInUnorderChunks; - unsigned long SctpFragUsrMsgs; - unsigned long SctpReasmUsrMsgs; - unsigned long SctpOutSCTPPacks; - unsigned long SctpInSCTPPacks; - unsigned long SctpRtoAlgorithm; - unsigned long SctpRtoMin; - unsigned long SctpRtoMax; - unsigned long SctpRtoInitial; - unsigned long SctpValCookieLife; - unsigned long SctpMaxInitRetr; - unsigned long __pad[0]; + __u64 SctpCurrEstab; + __u64 SctpActiveEstabs; + __u64 SctpPassiveEstabs; + __u64 SctpAborteds; + __u64 SctpShutdowns; + __u64 SctpOutOfBlues; + __u64 SctpChecksumErrors; + __u64 SctpOutCtrlChunks; + __u64 SctpOutOrderChunks; + __u64 SctpOutUnorderChunks; + __u64 SctpInCtrlChunks; + __u64 SctpInOrderChunks; + __u64 SctpInUnorderChunks; + __u64 SctpFragUsrMsgs; + __u64 SctpReasmUsrMsgs; + __u64 SctpOutSCTPPacks; + __u64 SctpInSCTPPacks; + __u64 SctpRtoAlgorithm; + __u64 SctpRtoMin; + __u64 SctpRtoMax; + __u64 SctpRtoInitial; + __u64 SctpValCookieLife; + __u64 SctpMaxInitRetr; + __u64 __pad[0]; }; struct linux_mib { - unsigned long SyncookiesSent; - unsigned long SyncookiesRecv; - unsigned long SyncookiesFailed; - unsigned long EmbryonicRsts; - unsigned long PruneCalled; - unsigned long RcvPruned; - unsigned long OfoPruned; - unsigned long OutOfWindowIcmps; - unsigned long LockDroppedIcmps; - unsigned long ArpFilter; - unsigned long TimeWaited; - unsigned long TimeWaitRecycled; - unsigned long TimeWaitKilled; - unsigned long PAWSPassiveRejected; - unsigned long PAWSActiveRejected; - unsigned long PAWSEstabRejected; - unsigned long DelayedACKs; - unsigned long DelayedACKLocked; - unsigned long DelayedACKLost; - unsigned long ListenOverflows; - unsigned long ListenDrops; - unsigned long TCPPrequeued; - unsigned long TCPDirectCopyFromBacklog; - unsigned long TCPDirectCopyFromPrequeue; - unsigned long TCPPrequeueDropped; - unsigned long TCPHPHits; - unsigned long TCPHPHitsToUser; - unsigned long TCPPureAcks; - unsigned long TCPHPAcks; - unsigned long TCPRenoRecovery; - unsigned long TCPSackRecovery; - unsigned long TCPSACKReneging; - unsigned long TCPFACKReorder; - unsigned long TCPSACKReorder; - unsigned long TCPRenoReorder; - unsigned long TCPTSReorder; - unsigned long TCPFullUndo; - unsigned long TCPPartialUndo; - unsigned long TCPDSACKUndo; - unsigned long TCPLossUndo; - unsigned long TCPLoss; - unsigned long TCPLostRetransmit; - unsigned long TCPRenoFailures; - unsigned long TCPSackFailures; - unsigned long TCPLossFailures; - unsigned long TCPFastRetrans; - unsigned long TCPForwardRetrans; - unsigned long TCPSlowStartRetrans; - unsigned long TCPTimeouts; - unsigned long TCPRenoRecoveryFail; - unsigned long TCPSackRecoveryFail; - unsigned long TCPSchedulerFailed; - unsigned long TCPRcvCollapsed; - unsigned long TCPDSACKOldSent; - unsigned long TCPDSACKOfoSent; - unsigned long TCPDSACKRecv; - unsigned long TCPDSACKOfoRecv; - unsigned long TCPAbortOnSyn; - unsigned long TCPAbortOnData; - unsigned long TCPAbortOnClose; - unsigned long TCPAbortOnMemory; - unsigned long TCPAbortOnTimeout; - unsigned long TCPAbortOnLinger; - unsigned long TCPAbortFailed; - unsigned long TCPMemoryPressures; - unsigned long __pad[0]; + __u64 SyncookiesSent; + __u64 SyncookiesRecv; + __u64 SyncookiesFailed; + __u64 EmbryonicRsts; + __u64 PruneCalled; + __u64 RcvPruned; + __u64 OfoPruned; + __u64 OutOfWindowIcmps; + __u64 LockDroppedIcmps; + __u64 ArpFilter; + __u64 TimeWaited; + __u64 TimeWaitRecycled; + __u64 TimeWaitKilled; + __u64 PAWSPassiveRejected; + __u64 PAWSActiveRejected; + __u64 PAWSEstabRejected; + __u64 DelayedACKs; + __u64 DelayedACKLocked; + __u64 DelayedACKLost; + __u64 ListenOverflows; + __u64 ListenDrops; + __u64 TCPPrequeued; + __u64 TCPDirectCopyFromBacklog; + __u64 TCPDirectCopyFromPrequeue; + __u64 TCPPrequeueDropped; + __u64 TCPHPHits; + __u64 TCPHPHitsToUser; + __u64 TCPPureAcks; + __u64 TCPHPAcks; + __u64 TCPRenoRecovery; + __u64 TCPSackRecovery; + __u64 TCPSACKReneging; + __u64 TCPFACKReorder; + __u64 TCPSACKReorder; + __u64 TCPRenoReorder; + __u64 TCPTSReorder; + __u64 TCPFullUndo; + __u64 TCPPartialUndo; + __u64 TCPDSACKUndo; + __u64 TCPLossUndo; + __u64 TCPLoss; + __u64 TCPLostRetransmit; + __u64 TCPRenoFailures; + __u64 TCPSackFailures; + __u64 TCPLossFailures; + __u64 TCPFastRetrans; + __u64 TCPForwardRetrans; + __u64 TCPSlowStartRetrans; + __u64 TCPTimeouts; + __u64 TCPRenoRecoveryFail; + __u64 TCPSackRecoveryFail; + __u64 TCPSchedulerFailed; + __u64 TCPRcvCollapsed; + __u64 TCPDSACKOldSent; + __u64 TCPDSACKOfoSent; + __u64 TCPDSACKRecv; + __u64 TCPDSACKOfoRecv; + __u64 TCPAbortOnSyn; + __u64 TCPAbortOnData; + __u64 TCPAbortOnClose; + __u64 TCPAbortOnMemory; + __u64 TCPAbortOnTimeout